Presentación: Contratos Ágiles - Agile Contracts. Actualización 2023-05-27

Hay que Ahorrar Costos, ya Aprendimos Ágil, Volvamos a la Estimaciones

Hola a todos

El COVID19 generó impactos a todo nivel, el primero y más doloroso de todos en vidas irrecuperables, pero adicionalmente continúa golpeando la economía, la forma en que trabajamos, nos reunimos, interactuamos, entre muchos otros. Hoy quiero poner luz en algo que he observado como Líder Regional Ágil dentro de una gran corporación, y es que muchos clientes en diferentes regiones afirman debido a la pandemia de forma más o menos similar: 

"¡Hay que controlar costos, ya aprendimos Ágil, volvamos a las estimaciones!"

 

Es decir, vamos a hacer estimaciones al inicio del proyecto pero ejecutaremos a tiempo, alcance, costo fijos, scrum con sprints fijos y plan de releases inamovible (te recomiendo leer; ¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles?), esto siempre me recuerda la citada frase de mi gran amigo Lucho Salazar @LuchoSalazarC) "Exigir los compromisos no los garantiza". Lamentablemente, nada más en contra de los propios intereses de la organización, pues pierde la organización y probablemente también lo haga el proveedor, estas son las razones:

• Una estimación buena implica conocer "TODO" desde el inicio, cosa que nunca tendrás, en un mundo tan cambiante como este, considerando adicionalmente la distorsión e inestabilidad que ha generado el COVID19.
• Genera desperdicios al construir producto innecesario que fue pactado a construirse totalmente desde el inicio.
• Genera desperdicios funcionales y técnicos de partes innecesarias.
• Nunca se logran identificar todas las dependencias a priori.
• El plan perfecto no existe, y como lo dice este tweet contestado por Elon Musk con un 100 : "El primer paso de cualquier proyecto es subestimar enormemente su complejidad y dificultad"
• Siempre que hay dependencias externas hay probabilidad alta de fallo, pues las dependencias no siempre están a tiempo.
• Implica que se construye algo que se pactó, así sea que se identifique que no va a generar valor
• Quien estima, extenderá tiempos en búsqueda de cubrir las incertidumbres.
• Entre más grande el proyecto, más grandes las suposiciones, más grandes los riesgos, más grandes "los colchones", mayor costo, y mayor probabilidad de fracaso.
• El enfoque en los costos y en el ahorro, pondrá foco en las áreas de gestión en el ahorro, en la maximización del tiempo comprado y en el cumplimiento estricto de lo pactado en etapas tempranas, pero por lo general (y lo he observado muchas veces), nunca se valida la generación de valor, ni se ve con buenos ojos la adaptabilidad a nuevas circunstancias.

Mi recomendación para estos casos siempre es:

• A nivel de priorización y estimación
• Priorizar las iniciativas con casos de negocio livianos, es decir, la estimación no podemos evitarla, pero no tiene sentido invertir demasiado tiempo en una actividad en la cual más le inviertas, más desperdicio es. 
• Usar como método de priorización de iniciativas del Costo del Retraso dividido por la duración (conocido como CD3 - Cost of Delay Divided by Duration - o WSJF -Weighted Shortest Job First -) (http://www.lecciones-aprendidas.info/2020/09/Un-Ejemplo-Practico-de-Gestion-Lean-Agile-de-Portafolio.html ver diapositivas18,19 y 20)
• Asignar un presupuesto al programa o portafolio de forma que se esten buscando siempre las alternativas de mayor impacto y valor para el negocio.
• Orientar las áreas de gestión a que se cuestione siempre la generación y validación del valor generado sobre el cumplimiento, ya hemos vivido, que cumplir el plan no implica generar valor, solo cumplir y ya. Son innumerables los casos de proyectos que se engavetan o nadie usa usa.
• A nivel de ejecución
• Poner un Product Owner empoderado que:
• priorice por valor
• acompañe al desarrollo
• decida qué construir y qué no sobre el producto
• asegure que se esté construyendo el producto correcto
• Validar constantemente la generación de valor, poniendo en producción versiones del producto, de forma que se identifique si se requiere detener el desarrollo o  perseverar para mejorar los resultados.

En resumen, el costo se controla más construyendo el producto correcto y valioso, que desde la estimación, al menos en el mundo de tecnología y desarrollo de soluciones de software.

Saludos ágiles,

Jorge Abad

FORO "COLABORACIÓN CON EL CLIENTE SOBRE NEGOCIACIÓN CONTRACTUAL" #AgilesCo2020

¡La base de los contratos ágiles es la confianza! 🤝

Comparto las notas visuales del Foro Colaboración con el cliente sobre Negociación Contractual, en @AgilesColombia 2020, edición Online.#agilesco2020 #contratosagiles #graphicrecording pic.twitter.com/nFdEzWPVPO

— Juliana Betancur (@julibetancur) August 22, 2020

Tabla Comparativa de la Triple Restricción (Alcance, Tiempo y Presupuesto) y su Compatibilidad para Contratos Ágiles

Hola a todos

Desde hace un tiempo tenía este pendiente, estas fichas técnicas y tabla comparativa de la triple restricción (alcance, tiempo y presupuesto) en un contrato y como esta puede ser usada para entornos de contratación ágil.

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo= fijo Presupuesto= fijo		baja
Ejemplos
Alcance= 70 funcionalidades Tiempo= 3 meses Presupuesto= 100.000 dólares		Alcance= 2000 funcionalidades Tiempo= 18 meses Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos. - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas.	Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, en el tiempo y presupuesto determinado. Entre más grande el proyecto o iniciativa peor será este impacto.		- Un alcance fijo no es buena práctica en un mundo VUCA(1). - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo= fijo Presupuesto=Variable		Media-baja
Ejemplos
Alcance= 70 funcionalidades Tiempo= 3 meses Presupuesto= lo que cueste		Alcance= 2000 funcionalidades Tiempo= 18 meses Presupuesto= lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas. - Priorice* las funcionalidades al momento de construirlas.	Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, tiempo determinado Entre más grande el proyecto o iniciativa peor será este impacto		- Un alcance fijo no es buena práctica en un mundo VUCA. - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio. - Es posible que por contar con presupuesto ilimitado trate de cerrarse el proyecto o iniciativa por fuerza bruta, pero es probable que "ni todo el dinero del mundo" ni los recursos alcancen a cerrarlo en la fecha pactada

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo=Variable Presupuesto=fijo		Media-baja
Ejemplos
Alcance= 70 funcionalidades Tiempo= lo que se demore Presupuesto= 100.000 dólares		Alcance= 2000 funcionalidades Tiempo= lo que se demore Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas.	Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, en el presupuesto pactado. Entre más grande el proyecto o iniciativa peor será este impacto		- Un alcance fijo no es buena práctica en un mundo VUCA. - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo= variable Presupuesto=variable		Media-alta
Ejemplos
Alcance= 70 funcionalidades Tiempo= lo que se demore Presupuesto=lo que cueste		Alcance= 2000 funcionalidades Tiempo= lo que se demore Presupuesto=lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos. - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas.	-Posiblemente no se logre resolver el problema pues el alcance fijo no garantiza que se construya lo que resuelve el problema		'- Un alcance fijo no es buena práctica en un mundo VUCA. - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato		Afinidad con Ágil
Alcance =variable   Tiempo= fijo Presupuesto=fijo		Alta-baja
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 3 meses Presupuesto= 100.000 dólares		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 18 meses Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el tiempo o el presupuesto, construyó lo de mayor valor primero	-Posiblemente no se logre resolver el problema con esas dos restricciones		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato		Afinidad con Ágil
Alcance = variable Tiempo= variable Presupuesto=fijo		Alta-media
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= Lo que se demore Presupuesto= 100.000 dólares		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= Lo que se demore Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solución para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el presupuesto, construyo lo de mayor valor primero	-Es posible que no se logre resolver el problema con esa restricción		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios. - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato		Afinidad con Ágil
Alcance =variable Tiempo= fijo Presupuesto=variable		Alta-media
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 3 meses Presupuesto= lo que cueste		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 18 meses Presupuesto= lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el el tiempo, construyo lo de mayor valor primero	-Es posible que no se logre resolver el problema con esa restricción. Es posible que como se cuentan con presupuesto sin restricciones, se trate de cerrar el proyecto o iniciativa en la fecha pactada, pero ni aun así se logre el objetivo		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios. - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato		Afinidad con Ágil
Alcance =variable   Tiempo= variable Presupuesto=variable		Alta-alta
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= lo que se demore Presupuesto= lo que cueste		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= lo que se demore Presupuesto= lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* constantemente las funcionalidades al momento de construirlas, que se garantice el mayor impacto	- No realizar una ejecución ágil del proyecto o iniciativa		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios. - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

* Se sugiere emplear la técnica de WSJF - weighted shortest job first

Puedes descargar en formato PDF aquí

Como siempre, bienvenida la retroalimentación

Saludos Ágiles

Jorge Abad.


Notas, Aclaraciones, Comentarios, Referencias y  Observaciones.

1. VUCA es un acrónimo utilizado para describir o reflejar la volatilidad, incertidumbre (uncertainty en inglés), complejidad y ambigüedad de condiciones y situaciones. Más información en  https://es.wikipedia.org/wiki/VUCA

Mis notas sobre la charla "El Corazón de la Agilidad" de Alistair Cockburn

Hola a todos

Hace poco mi gran amigo y líder técnico Daniel Ramirez, publicó las notas de la sesión que asistimos sobre el Corazon de la Agilidad de Alistair Cockburn - en Pragma el pasado mes de noviembre de 2019 -  https://contactosagiles.co/aoc-colombia-2019/el-corazon-de-la-agilidad/ -, yo también dejar un pequeño registro de ciertas frases contundentes que nos compartío Alistair en esta excelente sesión:

---

El corazón de la agilidad se basa en:

• colaboración
• entrega
• reflexión
• mejora

---

Combinando estas palabras se obtiene

• colabora para entregar
• entrega para reflexionar
• reflexiona para mejorar
• mejora la colaboración
• colabora para mejorar
• colaboramos para tener mejores ideas
• entrega para aprender
• la mejora reflexiva (es la inspección y adaptación de scrum)
• pausa para reflexionar (obvio no es una combinación)
• mejora para cambiar el mundo (obvio no es una combinación)
• mejora el sistema de entrega

---

Los tres estados del aprendizaje

• Shu - seguir la técnica
• Ha - agregar técnicas diferentes, romper la regla
• Ri-  dejar el dojo

---

Concepto clave Kokoro:

• esencia o corazón de algo
• simplificación radical de conceptos

---

Al hacer una transformación en una organización se debe buscar:

• no intentar cambiar la cultura
• aumentar la confianza
• reducir el miedo
• mejorar la interacción
• mejorar el sistema de entrega
• mejorar la conversación entre las personas

---

Respecto a la gerencia de proyectos y a los errores

• una empresa es una fábrica de ideas
• una idea es precursora de una decisión
• las decisiones son las molécula de lo que hacemos y entregamos al mundo
• cada producto tiene mas de 100.000 decisiones
• cada decisión es una posibilidad de error
• El "ARTE" de la gerencia de proyectos se basa hoy en día en DESCUBRIR LOS ERRORES LO MÁS TEMPRANO POSIBLE
• debido a lo anterior, entregamos lo antes posible para obtener feedback y evitar avanzar en la dirección equivocada

---

Preguntas para mejorar un equipo, un área, una organización:

Qué hacemos para: - Mejorar nuestra colaboración - Mejorar nuestra reflexión -Mejorar nuestra mejora

---

Notas y frases varias:

• si mi mundo es de contratación tradicional, es decir, alcance tiempo y costo fijo, sugiere hacer contratos de tres meses para poder adaptarnos dentro de esas restricciones
• Valor: el cliente sabe lo que es valor
• Una empresa será más ágil entre más NATURAL le podas dar MALAS NOTICIAS AL JEFE
• Debemos mejorar la conversación entre las personas
• el corazón de la agilidad es un recordatorio, no un proceso
• "Show me the feedback loops"
• Una métrica importante: ¿cuántas veces por dia o semana se interrumpe el trabajo del desarrollador?
• "Todo lo que se diga puede ser malinterpretado o malutilizado y no se puede escoger cual de ellos dos sucederá"
• "El corazón de la agilidad está en descubrir los errores y dar las malas noticias"
• SAFe que es nivel shu
• La resistencia al cambio es normal
• Cambia poco a poco

---

Otras imágenes de su pasada por Medellín

Tomado de: https://twitter.com/claudytoscano/status/1198794111735734272

"Nuestro trabajo en la Agilidad es dar las malas noticias temprano, simplemente porque es menos costoso"

---- 

"Agilidad es encontrar errores más rápido, y si no se los podes contar a tu jefe y virar, ¿para qué haces Agilidad?

---- 

Tomado de: https://twitter.com/claudytoscano/status/1198794111735734272

Tomado de: https://twitter.com/pablitux/status/1198710728707973121

---

Hasta acá este compartir

Video de la charla: http://www.lecciones-aprendidas.info/2022/09/video-corazon-de-la-agilidad-alistair.html


Saludos ágiles

Jorge Abad

Algunos ANS (Acuerdos de niveles de servicio) y Penalidades sugeridas en el Mundo del Desarrollo Ágil de Software

Hola a todos

En el pasado Ágiles 2019, presente la charla "Tips para una PMO perdida en el Mundo Ágil" - clic aquí -  y uno de los puntos en los cuales hay una constante inquietud por parte de las organizaciones tradicionales es:

¿Cuáles son las ANS (acuerdos de niveles de servicio )(1)  y penalidades aplicarían en un contrato de desarrollo ágil?

Responsabilidades en el Desarrollo Ágil

Para empezar, establezcamos responsabilidades bajo el esquema ágil

• el cliente es responsable del producto que esta requiriendo, o seá,
• tener claro el ¿para qué?
• ¿el Qué? 
• y que sea el producto correcto
• el equipo (que puede ser un proveedor externo) es responsable de la calidad técnica y funcional del producto que esta construyendo, es decir:
•  ¿Cómo esta construido? o
• ¿Construir el producto de forma correcta?
• el facilitador, líder, coach, Scrum Master, Agile Coach, que acompaña a cliente y equipo es responsable de la mejora continua de ambos y de lograr la mayor fluencia, es decir, la menor fricción entre cliente, equipo, y el entorno para ser exitosos, es decir:
• ¿Cómo interactuamos mejor?
• ¿Cómo podemos dar mejor resultado, y más rápido?

Los ANS Sugeridos y Deseables

Con este contexto, y habiendo clarificado que la responsabilidad del equipo es sobre "como construye el producto" les comparto algunos ANS, que se sugieren y que son deseables para el mundo ágil:

Tomado de (2)

Sugeridas

• Nivel de cumplimiento de los sprint (historias finalizadas/ historias de usuario acordadas). Valor sugerido>=80% (suponiendo que el marco de desarrollo sea Scrum)
• Calidad de los entregables (Defectos encontrados en Producción/Pruebas unitarias y de aceptación). Valor sugerido<=10%
• Efectividad de las pruebas (defectos encontrados en Producción/Cantidad de defectos). Valor sugerido<=10% 
• Deuda técnica (validación estática de código). Valor a acordar 

Descripción Objetivo Formula Medición Unidad Medición Valores Aceptación Peso Nivel de cumplimiento en los Sprints Controlar que las historias de usuario acordadas en cada sprint sean finalizadas por cada uno de los equipos (Historias de Usuario finalizadas por en cada sprint / total de Historias de Usuario comprometidas por en cada sprint) *100 % sprint  >= 80% xx% Calidad de los entregables Promover la calidad general del producto Cantidad de defectos encontrados en producción una vez se instale funcionalidades de un sprint  (Cantidad de defectos encontrados / Casos de pruebas unitarias + aceptación)*100 % sprint <=10% xx% Efectividad de las pruebas   Promover la calidad general del producto Porcentaje de defectos identificados en producción sobre el total de defectos encontrados (Número de defectos en producción / Total de defectos en fase de pruebas (Incluido unitarias, aceptación Y Producción))*100 % sprint <=10% xx% Deuda Técnica Promover la calidad técnica del producto % de deuda técnica identificada por el validador estático de código % sprint Valor a acordar (depende del producto) xx%

Deseables (Depende de la madurez en DevOps de la organización contratante y el equipo de desarrollo) 

• % de cobertura de pruebas unitarias. Valor a acordar 
• % de cobertura de pruebas funcionales automatizadas. Valor a acordar

Descripción Objetivo Formula Medición Unidad Medición Valores Aceptación Peso Cobertura de pruebas unitarias Promover la calidad técnica del producto del producto Cobertura de pruebas unitarias al código en % % sprint >= 80% xx% Cobertura de pruebas funcionales automatizadas Promover la calidad técnica y funcional del producto (Total de casos de pruebas funcionales automatizados/ Total de casos de pruebas funcionales) *100 % sprint >=70% xx%

Y las Penalidades

Las dejo a su consideración, realmente no estoy de acuerdo con el DPS (o Desarrollo Punitivo de Software) donde en el esquema de desarrollo tradicional o cascada se activan cantidades y cantidades de penalidades, tantas que como proveedor puedes terminar pagando económicamente al cliente cuando debería ser al contrario. Nadie se mete a hacer desarrollo de software (o a cualquier negocio) para terminar pagándole a su cliente.

Soy mas partidario de lo que comparto en la charla de contratos ágiles(3), tener esquemas de finalización anticipada, y si el cliente o el proveedor no dan la talla (el tema es mutuo), simplemente terminar la relación comercial sin penalidad alguna, con la ventaja que en el mundo ágil y específicamente con Scrum siempre tienes software de valor funcionando cada mes o menos (por lo general cada dos semanas).

Hasta acá este compartir

Saludos Ágiles

Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. También conocidos como SLA - Service Level Agreement, por sus siglas en inglés.
2. "Tips para una PMO perdida en el Mundo Ágil" - clic aquí - 
3. Hablemos de contratos ágiles - http://www.lecciones-aprendidas.info/2019/03/contratos-agiles-reoladed.html

Un tipo de Contrato que te permitirá trabajar en mundo Ágil - Contratos Ágiles

Hola a todos

Considerando que frecuentemente me preguntan cual es el tipo de contrato que mejor se lleva con la agilidad, y le es natural al cliente trabajar con el, les comparto estos slides de mi presentación de Contratos Ágiles (clic aquí):

----

---

---

Tomado de: http://www.lecciones-aprendidas.info/2019/03/contratos-agiles-reoladed.html

Más sobre contratos ágiles en: http://www.lecciones-aprendidas.info/search/label/contratos%20agiles