lunes, diciembre 30, 2019

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__ 
De
seo____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:
  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.

domingo, diciembre 22, 2019

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


Saludos ágiles

Jorge Abad

Tweet: Más valor menos trabajo



#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

   





sábado, diciembre 14, 2019

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.


viernes, diciembre 13, 2019

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


o descargar el excel que tambien contiene esta misma lógica
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

miércoles, noviembre 27, 2019

Ejemplo de reporte de la "PMO Ágil"

Hola a todos

Les comparto un ejemplo de reporte que podría realizar una "PMO Ágil", donde se observan los diferentes aspectos de la gestión del portafolio ágil (ver post anterior).

Recuerde, se puede incluir estos o diferentes campos de acuerdo a su contexto, esta es solo una propuesta que permite ver los aspectos de:
  • Construcción del Producto
  • Calidad del Producto
  • Salud de los Equipos
  • Uso del Producto
  • Desempeño del Producto en el Negocio
dentro del portafolio de productos que se están desarrollando con marcos ágiles.




Reporte General


A continuación cada una de las secciones.
Durante el Desarrollo o Construcción del Producto


Calidad del Portafolio 


Salud de los equipos



Uso del Producto

Desempeño del Producto en el Negocio
Con este tipo de reportes y de transparencia generada (ojala con una frecuencia de dos meses al mes), se podrán tomar acciones y la "PMO Ágil"(1) fungir como ese Scrum Master Organizacional: preocupada por:

  • La generación de valor
  • remover impedimentos organizacionales
  • promover la inspección y adaptación (agilidad) organizacional




Saludos Ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias


  1. En el mundo de