Ágil es - Agile is

---

    

   "Ágil es:

        Definición continua,

            Desarrollo continuo,

                Despliegue continuo y

                    Validación continua de valor"

---

    "Agile is:

             Continuous definition,

                 Continuous development,

                     Continuous deployment and

                         Continuous value validation" 

---

   

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

Tweet: "El primer paso de cualquier proyecto es subestimar enormemente su complejidad y dificultad". - Nicoll Hunt

 

 

"El primer paso de cualquier proyecto es subestimar enormemente su complejidad y dificultad". - Nicoll Hunt

"The first step of any project is to grossly underestimate its complexity and difficulty." – Nicoll Hunt

— Programming Wisdom (@CodeWisdom) January 23, 2021

Algunos ciclos en gestión de proyectos, gestión de productos, gestión de equipos en el mundo del software, por John Cutler

 ¿Por qué ese equipo siempre parece asumir demasiado trabajo?

 (Why does that team seem to always take on too much work? )

---

¿Por qué ese recurso compartido parece estar perpetuamente falto de personal?

(Why does that shared resource seem to be perpetually under-staffed?)

---

¿Por qué el equipo sigue empezando a planificar grandes lotes?

      (Why does the team keep slipping into planning big batches?)

---

¿Por qué una óptica miope se concentra en aumentar la velocidad, finalmente daña la calidad?

(Why does a myopic focus on increasing velocity eventually hurt quality?)

---

¿Por qué las historias del equipo nunca son "suficientemente buenas"?

(Why are the team’s stories never “good enough” ?)

---

¿Por qué mi equipo me oculta cosas?

(Why does my team hide things from me?)

---

Bueno ... viste lo que pasó cuando tratamos de asignarles un problema, ¿verdad?

(Well…you saw what happened when we tried to just hand them a problem, right?)

---

BONO (que envuelve muchas de estas)

{BONUS (that wraps up lots of these)}

---

Este es el tweet original

Some common loops #proddev #systems

1/7 Why does that team seem to always take on too much work? pic.twitter.com/AAbaTXzsQk

— John Cutler (@johncutlefish) November 22, 2019

FORO ERRORES COMETIDOS: C*GADAS EN AGILIDAD Y LECCIONES APRENDIDAS

Conversaciones del Scrum Master según la Madurez del Equipo

Hola a todos

Dentro de las charlas y acompañamientos que realizo a Scrum Masters y Agile Coaches, noto que muchos no conocen lo que se llama el liderazgo situacional, este fue propuesto por Hersey y Blanchard, y en el se explica que de acuerdo a la madurez del equipo, es la forma de delegar y empoderar  del lider (recomiendo ver (1)).

El Scrum Master es un lider servicial, que va llevando al equipo de desarrollo a ser cada vez mejor y más autoorganizado, para ser exactos la guía reza, en la parte del Scrum Master al servcio del equipo de Desarrollo, este debe  

"Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional" (2)

Por lo tanto, según la madurez del equipo se darán diferentes conversaciones que los Scrum Masters tendrán con sus equipos, a continuación un ejemplo:

• Equipo en Formación - Conversación tipo: Comando y Control
• "-Para que nos vaya mejor con los reportes de seguimiento que nos están pidiendo, vamos a dejar registro de la cantidad de horas que nos estamos gastando logrando una aprobación. ¿Quién se hace cargo? o sino, lo asigno."
• Equipo en Conflicto - Conversación tipo: Persuación
• "- ¿Les parece si revisan el log de transacciones?"
• Equipo en Normalización - Conversación tipo: Participación
• "-Yo he estado observando que hemos estado siendo más laxos con las pruebas no funcionales, ¿ustedes que piensan?
• Equipo en Desempeño - Conversación tipo: Delegación
• "-¿Qué creen que está sucediendo para que el desempeño de nuestro equipo no esté mejorando los últimos tres sprints?

Respecto a la Caducidad del Scrum Master

Ahora, en esa misma dirección, por lo general una pregunta asociada a este tipo de conversaciones es:

¿El Scrum Master caduca, o deja de ser necesario?

Es como si se afirmara,

como el equipo de fútbol llegó a ser campeón, ya no necesita director técnico

Obviamente, la respuesta es ¡No!, pues entre más maduro el equipo - aunque este requiere menos esfuerzo de facilitación-  las conversaciones cambian y están más ligadas al alto desempeño, y muy similares a las presentada en: Equipo en Desempeño - Conversación tipo: Delegación.

Para cerrar te comparto algo que me ha mostrado la experiencia,

• En la mayoría de los equipos en los que el Scrum Master ha sido removido, desaparece la retrospectiva y por ende la mejora continua

Saludos Ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización - clic aquí -
2. Guía oficial de Scrum- https://scrumguides.org/
3. Comenzando con un equipo en Scrum: Parte 2 - Ciclo de vida de los equipos - clic aquí-
4. Las Preguntas Poderosas como Herramientas para Generar Autoorganización y Autogéstión - clic aquí -.
5. Lecturas recomendadas:
• La caducidad del Scrum Master… y por extrapolación del coach ágil - clic aquí-.
• El objetivo de Scrum Master, NO PUEDE SER, dejar de ser necesario para el equipo - clic aquí -.

La estamos c*g*ndo con Scrum

La estamos c_g_ndo con scrum from Jorge Hernán Abad Londoño

Referencias

1. tamaño ideal de equipo entre 5 y 6 personas:

• http://www.intuitor.com/statistics/SmallGroups.html }
• https://medium.com/simply-agile/agile-leader-pattern-3-for-building-awesome-teams-small-is-big-7ce51ce4ac4b

Cómo evitar la "Ingenuidad Ágil", o sobre como tener éxito en proyectos ágiles en entornos tradicionales

Tomado de (1)

Hola a todos


En este acompañar equipos y organizaciones hacia el mindset ágil, con frecuencia he observado a Scrum Masters, e incluso Agile Coaches, ser ingenuos respecto al entorno en el que se encuentran y creer que su iniciativa, proyecto o producto ágil va a salir adelante solo con el burndown, burnup, kanban, uno que otro tablero y compartir sus pedidos de forma verbal con el o los interesados encargados de ayudar a la gestión del entorno empresarial, en efecto, esto debería ser suficiente pero la noticia cruel es que la mayoría de nuestros proyectos ágiles se desarrollan al inicio en entornos tradicionales, no amigables con el mindset ágil, por lo que  es necesario emplear herramientas de la gestión tradicional a modo de interfaz, como lo llamaría Michael Sahota (2).

Adaptado de (2)

Adaptado de (2)

Una de las herramientas que comúnmente sugiero, y bastante poderosa en entornos tradicionales es un informe semanal o quincenal con el estado de

• la gestión de riesgos
• la gestión de problemas o impedimentos

Claro, claro esto se puede gestionar con dos tableros,

o incluso con uno solo, que tenga dos carriles, unos impedimentos sean problemas a resolver lo antes posible y los riesgos sean problemas a resolver en el mediano plazo

y post-it que indiquen:

• descripción del problema o impedimento
• fecha de identificación
• persona a la que fue asignado
• días que lleva sin resolverse (pueden ser solo líneas en el post-it)

Pero un informe de carácter frecuente, con esta información con seguridad pondrá en evidencia la necesidad de gestión por parte del entorno tradicional.

Igual que un tablero, un informe frecuente también es transparencia.

Informe de Problemas o Impedimentos (3)

Informe de Riesgos(3)

como lo comparto muchas veces

"hasta que el entorno y las personas no muestren indicios de mindset ágil, deberemos interactuar con ellos con las herramientas a las que están acostumbrados y ayudarles a transitar a nuestro mindset"

Adaptado de (2)

Nota importante:
Esta misma ingenuidad la he visto en proyectos de gestión tradicional.


Bienvenidos sus comentarios

Saludos Ágiles
Jorge Abad

Notas, Comentarios, Aclaraciones y Observaciones

1. Photo on Visualhunt.com
2. Una guía de supervivencia a la adopción y transformación ágil: trabajando con cultura organizacional. Michael Sahota-  http://www.lecciones-aprendidas.info/2017/08/una-guia-de-supervivencia-la-adopcion-y.html
3. No dudo que estos reportes podrán tener más o menos información, deberán ser adaptados de acuerdo al contexto, pero recomiendo fuertemente:
• tener a alguien asignado para su resolución
• tener el tiempo de "no resolución"
• la importancia para el "proyecto"
4. Por lo general pongo "proyecto" (entre comillas) debido a que en el mundo ágil no se gestionan proyectos, sino productos.

Criterios para la Selección y el Éxito del Proyecto Piloto en Scrum

Hola a todos

Con cierta frecuencia comparto tips sobre como elegir el Proyecto Piloto en el mundo ágil, aquí va la lista de tips actualizada.

---

Se recomienda iniciar con proyectos que cuenten con los ciertos criterios que nos permiten tener un mayor impacto en la organización:

• Duración estimada de máximo 8 meses
• Contratación del proveedor bajo esquema ágil - ver más aquí -.
• Seguimiento bajo métricas ágiles.
• burndown chart para los sprints
• velocidad
• burnup chart para el Release
• Dedicación una persona experta en el negocio de al menos el 50%, la cual esté empoderada y no denigre de la agilidad.
• Un Scrum Master o Facilitador experto 
• Los impedimentos identificados por el Scrum Master o Facilitador serán atendidos y tendrán prioridad
• Las evaluaciones de desempeño de quienes participan en el proyecto no sean en cascada
• Las áreas de soporte le den prioridad al proyecto
• Ejecución por uno o dos equipos ágiles (15 personas máximo en total)
• Se debe de considerar tecnologías conocidas por los equipos
• Las personas de los equipos deben: 
• Contar con los skill técnicos
• Dedicación al 100%

Tomado de (1)

Si quieres conocer los post asociados a este tópico haz clic aquí - http://www.lecciones-aprendidas.info/search?q=piloto

Aclaraciones, Notas, Comentarios y Referencias

1. "Tips para una PMO perdida en el Mundo Ágil" - clic aquí - 

Antipatrón: Solo liderar la primera línea y no gestionar la red

Hola a todos

Quisiera compartir uno de las disfunciones que he observado en la gestión de equipos y de las redes vinculadas a los mismos, convirtiéndose en uno de los obstáculos en los esfuerzos  de cambio cultural y de liderazgo hacia ambientes de más colaboración, adaptación al cambio, innovación, mejora continua, y generación de valor.

Utilizaré el esquema de antipatrón para compartirlo.

Antipatrón: El líder solo exige y promueve un alto estándar a su equipo y no gestiona la red  de personas y el ecosistema a cargo.

Problema: El líder solo gestiona su equipo adyacente exhibiendo y demandando valores de alto estándar pero no valida si su equipo y su entorno lo está haciendo, infiriendo o suponiendo que su equipo hará lo mismo con las personas a cargo.

Consecuencias:
existen varias consecuencias

• positivas: que todo su equipo exhiba y demande estos valores de alto estándar generando una cultura altamente positiva.
• negativas: 
• que parte de su equipo exhiba y comparta hacia la red un alto estándar de valores y otra parte del equipo no lo haga generando una cultura desigual y heterogénea
• que su equipo no exhiba los valores con los que son tratados y se generen resultados maltratando a las personas, con una cultura de presión, irrespeto y miedo.

Causas:

• Inocencia del líder
• Tolerancia del líder de cualquier estilo de liderazgo sin importar el trato que se le da a su red

Solución

En caso de que el líder este interesado en que su cultura de alto estándar se propague por el resto de su red se sugiere:

• no confiarse de evaluaciones 360
• realizar reuniones o conversatorios con cierta cadencia (mensual, bimestral o trimestral) con los equipos de la red para validar estilos de liderazgo

Se me vienen a la mente dos citas relacionadas con este tema:

"La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar."- Gruenter and Whitaker, School Culture Rewired

"La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar"- Jurgen Appelo

Con base en lo expuesto en este post se le podría precisar algo a ambas citas:

"La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar en su equipo de trabajo y toda la red de personas a cargo"

----

"La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar en su equipo de trabajo y toda la red de personas a cargo"

y como dice Deming:“Todos ya están haciendo lo mejor que pueden; los problemas están con el sistema ... solo el management puede cambiar el sistema", pero el sistema somos nosotros (1) y como nos relacionamos, ahí se encuentra la clave para generar el cambio o promover un alto estándar de cultura y valores.

Hasta acá este compartir, bienvenidos sus comentarios.

Saludos Ágiles

Jorge Abad

Referencia

1. De Colección: Culpamos el sistema, pero el sistema somos nosotros  http://www.lecciones-aprendidas.info/2019/07/culpamos-el-sistema-pero-el-sistema.html

Una idea sobre cultura, propósito, principios, valores y procesos

Una conclusión a partir de tantas lecturas y observaciones:

"Los procesos no alcanzan a legislar sobre todo lo que ocurre en una organización y en ausencia de procesos: los valores, principios y cultura de la organización guiarán a lo colaboradores ante cualquier situación, incluso sobre cualquier proceso definido previamente.

Una buena cultura, principios y valores te guiarán al éxito, similar en caso contrario."

Una versión de Casca-Agile(TM) o Casca-Scrum: tener "Sprint de desarrollo y luego Sprint de pruebas"

Hola a todos

Hace unos años en Ciudad de México dictando un entrenamiento de Scrum y Principios Ágiles, en el momento de hablar de malas prácticas, uno de los asistentes (y amigo mío Ulises Soriano), bautizaba como:

Casca-Agile (TM)

cuando se tomaban cosas del mundo ágil y del de cascada, pero con el pésimo resultado de que no se obtenía ni la "predictibilidad" añorada de cascada, ni la adaptabilidad de Scrum.

Esté termino lo he seguido usando desde ese entonces, y luego de tener la oportunidad de compartir con tantas organizaciones a nivel Latinoamérica he observado que hay una versión de Casca-Agile común a muchas empresas que no quieren adoptar la agilidad por completo: y es que contratan a un proveedor para que haga Scrum en el desarrollo del software y otro proveedor para que haga Scrum en las pruebas, olvidando lo que tanto se enuncia el marco Scrum en dos apartes:

"El Equipo de Desarrollo consiste en los profesionales que realizan el trabajo de entregar un Incremento de producto “Terminado” que potencialmente se pueda poner en producción al final de cada Sprint. Un Incremento “Terminado” es obligatorio en la Revisión del Sprint. Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento."(1)

"Los Equipos de Desarrollo son multifuncionales, esto es, como equipo cuentan con todas las habilidades necesarias para crear un Incremento de producto;"(1)

Esa versión de Casca-Agile o Casca-Scrum, termina viéndose así:

Añadiendo al menos 3 sprints (pueden ser más) entre el desarrollo de la historia de usuario y el lograr la "certificación"por parte de pruebas

Las desventajas que esto genera

• Largos tiempo de entrega del incremento (al menos tres sprints más)
• La imposibilidad de revisar el incremento completo cuando se termina cada sprint de desarrollo por parte del PO.
• Bajo involucramiento del PO
• La Definición de Terminado o "Definition of Done" toma mucho tiempo para que sea completamente alcanzada por ambos equipos
• la responsabilidad sobre el producto construido no existe.
• Gestion de ANS (acuerdos de niveles de servicio) que no agregan valor y desfiguran el marco de Scrum.
• El equipo de testing no esta sintiendo la construcción incremental del producto y por lo tanto no se sienten responsables del la buena construcción del mismo
• Esto no es Scrum y se aleja de la agilidad pues no cumple ni con la definción de Scrum, ni con los valores y principios del manifiesto ágil (2)
• A esto muchos se atreven a llamarlo Scrum, sabiendo que no lo es, o lo llaman "Scrum pero" (o ScrumBut (3)), y si no les funciona le echan la culpa a Scrum.

Las ventajas

• Le pienso y le pienso y no lo encuentro, puede que saboreen un poco las mieles del desarrollo iterativo e incremental, pero deja mucho que desear.

Solución a este antipatrón

La "falsa sensación de seguridad" de tener dos contratos, uno para el proveedor de desarrollo y otro para el proveedor de pruebas, se resuelve sentándolos juntos en una sola mesa y siendo ambos responsables de la calidad del producto entregado, cada sprint.

Cerrando

Bien parafrasean muchos a Jeff Sutherland,

"el peor enemigo de Scrum, es un mal Scrum" 

o mejor como él lo dice:

Referemcia(4)

Hasta acá este compartir, bienvenidos los comentarios y experiencias.

Saludos ágiles
Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. La Guía Oficial de Scrum - https://scrumguides.org/
2. Manifiesto por el Desarrollo Ágil de Software -https://agilemanifesto.org/iso/es/manifesto.html
3. Una excelente definición de ScrumBut - https://www.scrum.org/resources/what-scrumbut
4. https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/
5. Si deseas ver más disfunciones de Scrum y de Ágil, haz clic aquí. http://www.lecciones-aprendidas.info/2019/04/malos-olores-en-transformaciones-agiles.html

DevOps sin Gestión por Valor También es Desperdicio

Podemos tener el mejor Pipeline de DevOps, pero si no existe: Priorización de Portafolio  Priorización de Product Backlog y validación de hipótesis a nivel de iniciativas y épicas. Seguiremos generando desperdicio y perdiendo costo de oportunidad.

We could have the best DevOps Pipeline, but if it does not exist: Portfolio Prioritization   Product Backlog Prioritization  and hypotheses validation at level of initiatives and epics.. We will continue generating waste and losing opportunity cost.

---

Podemos tener el mejor Pipeline de DevOps, pero si no existe:
- Priorización de Portafolio
- Priorización de Product backlog
- y validación de hipotesis a nivel de iniciativas y épicas.

Seguimos generando desperdicio, y perdiendo costo de oportunidad.

— Jorge Hernán Abad L. (@jorge_abad) May 15, 2019

---

We could have the best DevOps Pipeline, but if it does not exist:
- Prioritization of Portfolio
- Prioritization of Product Backlog
- and hypotheses validation at level of initiatives and epics.
We will continue generating waste and losing opportunity cost. #Agile #DevOps

— Jorge Hernán Abad L. (@jorge_abad) May 15, 2019

---

¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles? (o ¿Por qué no puedes contratar en alcance, tiempo y costo fíjo un proyecto ágil?)

Por:
Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)

Aunque en varios foros hemos compartido que contratar en Cascada (o tradicional, o con alcance, tiempo y costo fijos) un proyecto (o mejor, producto) ágil es completo dolor de cabeza para ambas partes, es como querer jugar rugby con las reglas del del fútbol, en este post, quisiéramos compartirte unas ideas claves de por qué no te conviene hacer esto tanto desde del punto de vista del Cliente como del Proveedor, vamos pues:

Problemas desde el punto de vista del Cliente

• El alcance no puede ser fijo en estos tiempos de alta disrupción (VUCA (1)) y es un error tratar de definir los requisitos a priori dada esta misma volatilidad(2) 
• El proceso de control de cambios (no te agregaría ningún valor)haría muy lenta las decisiones, y retrasaría el Time to Market, considerando que en ágil existe una continua repriorización y modificación de los requisitos en función del valor. 
• Tal vez (la verdad, muy seguramente) te obligues a construir lo innecesario. 
• Como la responsabilidad no es compartida, se genera una relación de competencia en vez de una relación de colaboración, impidiendo maximización del valor del producto. 
• Las estimaciones y costos con seguridad estarán inflados debido a la incertidumbre 
• Quemarás al proveedor y al equipo de trabajo, pues estos fallarán continuamente en sus estimaciones. 
• Los contratos tradicionales se basan en la desconfianza. Esto aumenta la incertidumbre y maximiza los riesgos. La incertidumbre y los riesgos nunca son buenos para el cliente, generan presión y desgaste. Se pierde el foco en lo que es realmente importante: el valor para la organización y la oportunidad. 
• Los planes se basan la percepción y no en la realidad. Lo que conduce a que haya una dedicación exclusiva a "cuidar" esos planes. Esto es desperdicio. Pérdida de dinero. Dinero del cliente. 
• La realidad es lamentable: con un contrato tradicional siempre o casi siempre hay desviación por sobrecostos, esto “hiere” mortalmente la confianza interna del cliente, es decir, entre las áreas involucradas. 
• Los continuos cambios pueden ocasionar modificaciones en las cláusulas en el contrato. Allí surgen roces entre las partes, proveedor y cliente. 

Problemas desde el punto de vista del Proveedor

Nota: este tipo de espantajos metodológico-contractuales por lo general se contratan bajo la siguiente forma: un alcance definido o que se define durante los primeros dos o tres meses y luego se hace una estimación que se parte en sprints.

• De entrada sabes que la estimación es fallida, que debes incrementar costos y tiempos y no tienes como justificarlo, y aunque lo justifiques el cliente no te creerá haciendo reducir costos y tiempo (pues el alcance lo dejan fijo) y exponiéndote a un riesgo financiero, reputacional o de penalidades. 
• Aunque estimes a priori el proyecto y ejecutes por sprint, te atrasarás debido a la incertidumbre de reinante en el mundo del software, incrementando la presión sobre el proyecto y la ejecución 
• Te la pasarás reunión tras reunión justificando por qué no estás cumpliendo el plan (sabiendo que trabajas en scrum con sprints) y tratando de reacomodar el plan 
• Los controles de cambio son un dolor de cabeza que no te permite realizar priorización por valor que le conviene más al cliente y al proyecto (producto) 
• Las métricas de seguimiento cascada aplicadas al proyecto (o producto) en ágil generan un desgaste pues no hacen match con las métricas de seguimiento ágil. 
• Quemarás a tu equipo tratando de ponerte al día con el cronograma de sprints comprometido al principio del proyecto.

Soluciones

• Contrata en ágil los proyectos ágiles (ver nuestro video sobre contratos ágiles - https://www.youtube.com/watch?v=872uF0dPYd8) 
• Pon cláusulas de terminación anticipada, que te sirvan cuando decidas no continuar con el cliente o con el proveedor según el caso. 
• En un contrato ágil nunca pongas el alcance fijo. 
• Si te preocupan los ANS o SLA, en Scrum tienes software funcionando cada dos semanas lo que permite validar si el proveedor está construyendo el producto de forma satisfactoria. 

Si tienes alguna otra disfuncionalidad a compartir, no dudes en hacerlo en la zona de comentarios


Saludos Ágiles

Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)

Referencias, comentarios, notas y aclaraciones

1. VUCA. Las siglas en inglés de Volatilidad, Incertidumbre, Complejidad, Ambigüedad. Más en https://hbr.org/2014/01/what-vuca-really-means-for-you
2. Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software - http://www.lecciones-aprendidas.info/2015/04/radioactividad-de-los-requisitos.html
3. Este artículo fue escrito a cuatro manos, y fue publicado en el Gazafatonario IT en http://www.gazafatonarioit.com/2018/11/por-que-no-debes-contratar-en-cascada.html

Tip sobre Proyectos y Contratos Ágiles

"Hacer un Producto/Proyecto Ágil con un contrato tradicional (alcance, tiempo y costo fijos) es un completo dolor de cabeza para todos -cliente y proveedor-. Es como jugar fútbol con las reglas del rugby.

Tip: una de las tres restricciones debe liberarse, preferiblemente el alcance."

_

Hacer un producto/proyecto #Agile con un contrato tradicional (alcance, tiempo y costo fijos) es un dolor de cabeza para todos. Es como jugar fútbol con las reglas del rugby.

Tip: una de las tres restricciones debe liberarse, preferiblemente el alcance https://t.co/M2FkrzODN2

— Jorge Hernán Abad L. (@jorge_abad) October 24, 2018

MiniManual para la Gestión por Valor

MiniManual para la Gestión por Valor

1.¿Añade valor construir más alcance?
-si, construye más alcance y pon el siguiente hito lo más cerca posible y regresa a 1
-no, ¿por qué?
-Logramos el valor, resuelto el problema
-no, la hipótesis falló, no tiene sentido continuar#Agile

— Jorge Hernán Abad L. (@jorge_abad) August 23, 2018

Dos ideas sobre Agile

Dos ideas

- No seas ilus@, #Agile no va a resolver tus problemas, lo que si va a hacer es a evidenciarlos más rápido.

- Si tu gestión es basada en la falta de transparencia, no uses #Agile pues rápidamente te pondrá en evidencia.

— Jorge Hernán Abad L. (@jorge_abad) August 7, 2018

Presentación: Las Cinco Disfunciones de los Equipos y el Miembro de Equipo Ideal

Las Cinco Disfunciones del Equipo y el Miembro de Equipo Ideal from Jorge Hernán Abad Londoño

Tweet: Agile no gestionar por alcance sino por valor

Entre los grandes cambios que introduce #Agile en una organización es pasar de

La Gestión del Alcance a la Gestión del Valor

Este "simple" cambio de enfoque:
-reorganiza equipos
-cambia métricas
-elimina desperdicios
-conecta más a las personas
-aumenta la felicidad

— Jorge Hernán Abad L. (@jorge_abad) April 17, 2018

¿Cómo desbloquear el miedo de tu cliente hacia la Agilidad? o ¿Cómo vender la Agilidad?

Hola a todos

A continuación les comparto una conversación que puede ayudar a desbloquear los miedos hacia la agilidad en tu interlocutor, ya sea PMO, Gerente, Director o Vicepresidente de IT, o alguien similar:

- [Promotor de la Agilidad]¿Cuánto del software que crees que actualmente y/o produces es usado?
- [Cliente] (Por lo general responde) entre el 50 % al 60%
- [Promotor de la Agilidad] El número generalmente es del 50% o menos (muestras como el Principio de Pareto también se cumple en Software(1)), pero que implica eso:

• que el 50% del tiempo del ultimo año lo pudiste no haber trabajado y el resultado sería el mismo,es decir, se pudo haber trabajado 6 meses o solo medio tiempo y el resultado obtenido es el mismo.
• al menos el 50% de tu dinero fue desperdiciado
• que te esta pasando lo contrario a lo que querías controlar con tus contratos y fue construir lo que no era.
• que el control predictivo no ha servido y ha generado un 50% de desperdicio (una de las razones es la inestabilidad actual de los requisitos (2))
• que tuviste al menos 50% de reuniones innecesarias de requisitos, 50%  de software en el servidor (si no es más) que no funciona,  50% de pruebas innecesarias, 50% de reuniones de aceptación y pruebas UAT que no era necesarias.
• que ese 50% de desperdicio es costo y tiempo de oportunidad que estas dejando de ofrecer a tus clientes externos e internos por hacer cosas que no servían.

-[Promotor de la Agilidad] por lo tanto en ágil tienes

• Software de valor cada dos semanas 
• Transparencia
• Si el proveedor no da la talla, a lo sumo se perdió dos semanas o máximo un mes
• puedes parar cuando quieras, o cuando una linea adicional de código no genere el ROI que compense su creación.
• Llegas más rápido a la solución, no porque la gente codifique más rápido, sino porque construyen menos desperdicio, implicando llegar más pronto a la solución buscada
• Liberas capacidad operativa que puede ser usada en innovación o en mejora operativa.

-[Promotor de la Agilidad] Si lo deseas comenzamos con un piloto pero debemos generar las condiciones que funcione la agilidad:

• Acompañamiento en el proceso, pues no puedes gestionar ágil bajo la misma mentalidad de cascada o tradicional
• Un Product Owner al menos un 50% del tiempo con el equipo
• Un contrato ágil para el proveedor, o al menos tiempo y materiales.
• Unas métricas de seguimiento ágil distintas a las de cascada
• Un piloto con condiciones para ser exitoso (3)
• Ambientes de desarrollo, pruebas lo más parecidos a producción y listos desde el inicio del primer sprint
• Un equipo de desarrollo competente
• Liberarse de los ANS o SLA, pues en Ágil no tienen mucho sentido (4)

-[Cliente] ¿Pero es que me han dicho que ágil es más costoso que cascada?

-[Promotor de la Agilidad] Pues sino te ha parecido muy costoso construir el 50% o más de software desperdicio durante los últimos años, no te va a doler hacer agilidad, además a cascada ya le has dado muchas oportunidades y en ocasiones no has ni entregado el proyecto, ¿por qué no te das el lujo de hacer bien ágil y ver que resultados obtienes?

-[Promotor de la Agilidad] ¿Cuando comenzamos?

Cerrando

La verdad no fue tanto un diálogo, fue más un monólogo, pero espero encuentres en este post elementos para ayudarte avanzar hacia la agilidad con tu interlocutor.

Bienvenido el feedback y éxitos en tu intención.

Saludos ágiles

Jorge Abad

Referencias

1. Pareto se cumple en software, clic aquí 
2. Los requisitos son más inestables hoy que en el pasado. clic aquí
3. Condiciones para selección del proyecto piloto, clic aquí.
4. Sobre RFP, ANS o SLA para desarrollos ágiles y otras perversiones, clic aquí.