domingo, enero 31, 2021

Haciendo Retrospectivas Inútiles

 



Las retrospectivas perderán valor o terminarán perdiendo importancia bajo varias circunstancias:

  1. Las mejoras no se implementan, convirtiéndose en un ritual sin valor.
  2. Similar al anterior, las mejoras escaladas hacia el entorno, es decir, fuera del equipo no son tenidas en cuenta, ni consideradas.
  3. Se vuelven un rito para el equipo, el cual tiene que hacer, porque así lo dice un proceso, pero no se vuelve un espacio de aprendizaje y reflexión.
  4. Cuando se hacen con afán o a la carrera, buscando terminar rápido y posiblemente terminen con: “envíenme un email con sus mejoras, yo las organizo”.
  5. Cuando una persona es la que manipula las retrospectivas, opacando al grupo.
  6. Cuando existe temor, desconfianza y no hay transparencia.
  7. Siempre se realizan las mismas actividades de interacción.
  8. Las mejoras implementadas son carentes de valor y no generan impacto, ni retan el statu quo del equipo. 
  9. Se juega, se come, se brinda, se hacen bromas, es decir, se hace de todo, pero no hay una reflexión sobre el pasado y acciones concretas hacia el futuro.

Evita por tu bien y el de tu equipo las retrospectivas inútiles.


Saludos ágiles

Jorge Abad




Este es uno de los miniartículos del mi minilibro: "Algunas ideas sobre retrospectivas". ¿Querés saber más sobre retrospectivas o cómo desarrollo este concepto en el minilibro?

A continuación te comparto el link en Amazon:

domingo, enero 24, 2021

Video: Scrum: cambió la guía ¿y ahora qué hago?



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


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


lunes, enero 18, 2021

Retrospectivas con Propósito

 


En ocasiones el facilitador puede al principio de la sesión compartir una pregunta o propósito poderoso que requiere resolverse en la retrospectiva.

La idea es que conjuntamente todas las actividades y agenda de la retrospectiva giren alrededor de ese propósito compartido.

Este propósito puede identificarse tanto por el facilitador y los hechos que observó, sugerido por algún miembro del equipo o alguien externo.

Algunas ideas de preguntas o propósitos poderosos pueden ser:

·         ¿Qué tenemos que hacer para ser un equipo de alto rendimiento?

 

·         ¿Cómo vamos a resolver la deuda técnica que nos atormenta?

 

·         ¿Qué nos está apartando de nuestro propósito como equipo?

 

·         ¿Cómo vamos a mejorar las interacciones con “x” área de la organización?

 

·         ¿En qué reprocesos estamos incurriendo? ¿Cómo los estamos generando? ¿Cómo podemos evitarlos?

 

·         ¿Qué actividades nos están desenfocando comúnmente de nuestro objetivo del sprint?

 También puede ser poner una palabra o concepto y conversar alrededor de él, algunos ejemplos pueden ser:

·         Software funcionando sobre documentación extensiva


·         Interacción

 

·         Resultados

 

·         Cambio

 

·         Empatía

 

·         Excelencia

 

·         Respeto

 

·         Comunicación

 

·         Mejora implacable

 

·         Flujo

 

·         Valor

 

·         Desperdicio

 

·         Valores de Scrum

 

·         Valores del Equipo

 

·         Valores de la Organización a la que se pertenece

 

O tal vez, por votación elegir entre varios de estas ideas claves u otras que te llamen la atención. 

Se requiere de lectura del facilitador respecto al equipo, es decir, entender el momento que están atravesando, para saber si el tema debe ser abordado o aplazado.

Una buena finalización de la retrospectiva sería evaluar con los asistentes las siguientes preguntas:

 

·         ¿Logramos el propósito que buscábamos con esta retrospectiva?

 

·         ¿algo que consideren que deba ser compartido?

 

Saludos ágiles

Jorge Abad




Este es uno de los miniartículos del mi minilibro: "Algunas ideas sobre retrospectivas". ¿Querés saber más sobre retrospectivas o cómo desarrollo este concepto en el minilibro?

A continuación te comparto el link en Amazon:

miércoles, enero 13, 2021

Los Dos Movimientos de la Retrospectiva

Una retrospectiva requiere de dos movimientos claves, una mirada para entender el pasado y una para el futuro. Se asemeja a la diástole y la sístole del corazón, los movimientos de la retrospectiva: 


Diástole = ¿Qué pasó?

Sístole = ¿Qué vamos a hacer?


Sin importar el formato, la guía, el esquema que encuentres, si logras resolver estos dos movimientos en tus retrospectivas estarás logrando el objetivo para el cual fueron planteadas en entornos ágiles.





Este es uno de los miniartículos del mi minilibro: "Algunas ideas sobre retrospectivas". ¿Querés saber más sobre retrospectivas o cómo desarrollo este concepto en el minilibro?

A continuación te comparto el link en Amazon: