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

Dos Errores Comunes en las Historias de Usuario

Hola a todos

Aunque a través de varios escritos y post (1) he compartido que el formato de las historias de usuario es un formato libre,  pues

"cualquier modo de escribir o representar las Historias de Usuario sirve, siempre y cuando el Product Owner y el Equipo de Trabajo tengan la misma imagen mental de lo que se está requiriendo construir."

Pero, si un equipo se siente cómodo empleando la plantilla popularizada(2) por Mike Cohn,

Yo como _____ROL____ Deseo____UNA FUNCIONALIDAD___ Para_______BENEFICIO DE NEGOCIO__

La cual es ampliamente usada, ¡pues está bien!, ¡no hay lío con eso!.

Ahora, respecto a esta plantilla (la de Mike Cohn) quisiera compartirles dos errores frecuentes que he observado acompañando equipos de diferentes organizaciones:

El Primero, cuando se pone la historia de usuario en voz del Product Owner

Yo como _____PRODUCT OWNER____ Deseo____REGISTRAR LOS EGRESOS MENSUALES_   Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____

Y El Segundo, cuando ponemos la historia de usuario en voz del área funcional que la solicita

Yo como __VICEPRESIDENCIA FINANCIERA__ Deseo____REGISTRAR LOS EGRESOS MENSUALES____  Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____

La Forma Correcta es escribirla en voz de la persona que hace clic en el sistema, es decir, de quien usa la funcionalidad, que en este caso sería el SOLICITANTE DEL PRÉSTAMO, quedando la historia de usuario "bien escrita" de la siguiente forma:

Yo como _____SOLICITANTE DE PRÉSTAMO__  Deseo____REGISTRAR LOS EGRESOS MENSUALES____  Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____

Hasta acá este compartir

Saludos Ágiles
Jorge Abad

Referencias, Notas, Aclaraciones y Comentarios

1. Algunas referencias son:
• Libro de Historias de Usuario (clic aqui)
•  Modos de Representación de las Historias de Usuario - Un Capítulo del Libro Historias de Usuario una Visión Pragmática - clic aquí
• [De Colección] Lo más importante de las historias de usuario no es el formato sino la esencia - Tweet de Colección
• Algunos Tweets Importantes sobre Historias de Usuario
2. La plantilla fue desarrollada por Rachel Davies en la compañía Connextra de Inglaterra, en 2001, pero luego la popularizó Mike Cohn junto a otros entusiastas del modelo.

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

Tweet: Más valor menos trabajo

Agile: More value from less work, not done twice the work in the same time ⁦@TotherAlistair⁩ #HeartOfAgile #leandigital pic.twitter.com/YAFigGYI2r

— Marc Legru (@MarcLegru) October 8, 2019

#hormigasagilistas "EP16 — PMO Agile y Métricas con Jorge Abad"

Hola a todos

Les comparto esta interesante conversación sobre PMO Agile y Métricas que tuve la oportunidad de compartir con mis amigos de Hormingas Agilistas, Felipe Talavera y Rodrigo Burgos.


Estas son sus redes sociales
Facebook - https://www.facebook.com/HormigasAgilistas/
Linkedin - https://www.linkedin.com/feed/hashtag/?keywords=%23HormigasAgilistas
Twitter - https://twitter.com/HormigasPodcast

Espero la disfruten tanto como nosotros


Saludos ágiles
Jorge Abad

 

El Agilismo en la Seguridad y Salud en el Trabajo - Jirafas en el Everest

Les comparto esta interesante conversación con mi gran amigo Hugo Londoño, director de innovación de Cultura Segura

Disfrútenla tanto como nosotros

Gracias Hugo y equipo de Cultura Segura. Fue un gran honor.

Una herramienta para comparar culturas, basada en Reinventar Organizaciones de Laloux

Tomado de (1)

Hola a todos

Hace poco con la ayuda de mi compañera Ivonne Delgado, logramos tabular el mapa de https://www.facebook.com/groups/reinventing.organizations.map/ en donde se muestran los diferentes aspectos de las  culturas que caracterizó Frederic Laloux en su Libro Reinventar Organizaciones (2)(3), con el objetivo de poder usarlo en evaluaciones culturales.

Las culturas que agrupó Laloux en su libro son:

Impulsivo-Rojo
Bien adaptado a ambientes caóticos pero inadecuado para lograr resultados complejos en ambientes estables.

Valores:

• Autoridad de comando, división del trabajo

Conformista-Ambar
Puede Planear a largo plazo y crear estructuras organizacionales que son estables y escalan.

Valores:

• Perspectivas a largo plazo, tamaño y estabilidad, roles formales, procesos

Logro-Naranja
La eficacia reemplaza la moral. Cuanto mejor entiendo la forma de operar, más puedo lograr.

Valores:

• Innovación, meritocracia, rendición de cuentas.

Pluralista-Verde
Busca justicia, igualdad, armonía, comunidad, cooperación y consenso. Insiste en que todas las perspectivas merecen igual respeto.

Valores:

• Empoderamiento, cultura dirigida por valores, perspectivas de múltiples involucrados.

Evolutivo-Teal
Puede aceptar que hay una evolución de la consciencia, que hay un impulso en la evolución hacia formas más complejas de tratar el mundo.

Valores:

• Propósito evolutivo, integridad, autoorganización.

Estas diferentes culturas conviven en una organización, pero una es más predominante que las otras. Justo para entender como estaba esa distribución actual y cual es la distribución deseada por un subconjunto o muestra de la organización,  se construyo este instrumento.

Para lograr esto, se armaron dos formularios de google docs, uno que pregunta sobre el estado actual de la cultura y otro que pregunta sobre el estado deseado.

Sobre 20 aspectos o rasgos de cultura:

• conocimiento habilidades comportamiento        
• estilo de liderazgo
• toma de decisiones
• desarrollo personal
• resolución de conflictos
• reuniones
• productos procesos y estructuras            
• estructura de la organización
• proceso
• flujo de información y comunicación
• eficiencia de recursos
• salario
• productos y servicios
• valores cultura y relaciones        
• relación con involucrados
• actitud hacia el trabajo
• visión y valores centrales
• clima de trabajo
• lealtad
• pensar sentir actitud      
• miedo
• actitud durante el contacto
• motivación interior, impulso a manifestarla
• conciencia de uno mismo

Estos formularios se pusieron a apuntar a un archivo de google docs, que los tabula y resume.

En el siguiente link puedes encontrar la carpeta de google docs donde hay una copia de los formularios y de la hoja de calculo

• https://drive.google.com/drive/folders/1w9elFQzVE1waeLmZu04_KZAGJ0_kLTaL?usp=sharing

o descargar el excel que tambien contiene esta misma lógica

• https://drive.google.com/file/d/1gGIOP3x09x3iOqNU2g1_RCOgqfEryEhK/view?usp=sharing

No dudo que jugando un poco logres entender como estan organizados los formularios y  la hoja de calculo de google y los resultados obtenidos.

Los Resultados

Con un grupo de amigos realizamos una pequeña simulación y de allí obtuvimos los siguientes resultados.

Lo cierto, es que las veces que he usado instrumentos similares los rasgos culturales actuales y deseados tienden a ser los mismos, pues la mayoría de nuestras organizaciones son jerárquicas, orientadas a procesos y al logro, y por lo general deseamos organizaciones dirigidas por el propósito con más autoorganización.

Cerrando

Aun falta perfeccionar la herramienta, si encuentras algún error no dudes en compartirlo. 

Y si la usan dejen su nota en los comentarios, hagan un post, o pongan un link con su análisis referenciando este post y este instrumento.

Bienvenido el feedback

Saludos ágiles

Jorge Abad

Comentarios, Referencias, Notas y Aclaraciones

1. Photo on Visual Hunt
2. https://www.reinventingorganizations.com/
3. Libro que recomiendo ampliamente si estas interesado en colaborar o trabajar en procesos de cambio organizacional