De colección: Un excelente tweet sobre estimación, esfuerzo y capacidad

Sea lo que sea que uses para estimar esfuerzo en equipos ágiles, que sea relativo, porque el esfuerzo fijo al igual que el costo fijo, es un engaño de nuestra necesidad de control. Estimamos para conocer nuestra capacidad, no para cumplir la estimación. #adaptation #agilemindset

— Claudia Toscano Varg (@claudytoscano) April 18, 2019

Una pequeña reflexión sobre los radares, las métricas y los modelos de madurez ágiles

A ratos veo tantos "modelos" ágiles, radares, métricas, modelos de madurez ágil para organizaciones, equipos, personas, roles, etc. que me da la sensación que terminamos pareciéndonos más CMMi, y a marcos tradicionales que a la agilidad que promulgamos. Tendemos a parametrizar todo, es nuestra inclinación innata, tratamos de generar fórmulas, y estandarizar y generar patrones.

Pero olvidamos que el "driver" principal es la generación de valor al cliente, llegarle con mejores servicios y de forma temprana y continua; los radares, las métricas, los modelos de madurez son secundarios.

Las únicas métricas importantes en todo esto son: si generamos valor y si estamos sobreviviendo en el mercado, el resto es informativo.

El Equipo Oculto de Scrum: El Equipo del Product Owner o Equipo del Producto

Hola a todos

Este corresponde a uno de esos post que tengo en mi lista de pendientes que por fin salen a la luz después de presionarme internamente una y otra vez por ser escritos.

Definitivamente el título del artículo es el "spoiler", pero aunque saben para donde voy, vamos a conocer las razones de esta afirmación.

Un Product Owner con Pleno Conocimiento

En primer lugar, tenemos equipos scrum, con esquemas muy simples de trabajo donde el Product Owner (PO), es alguien que tiene todo el conocimiento sobre el producto y le es fácil tomar decisiones sobre lo que se esta construyendo.

Desde mi punto de vista esta es la configuración más simple pero muy escasa, principalmente en espacios corporativos, pues muchas veces para diseñar un Producto un PO debe interactuar con muchos interesados; y eso nos lleva a la siguiente configuración.

Un PO Interactuando un Grupo de Interesados

En este caso el PO, posible que tenga conocimiento de una parte del universo del problema pero requiere de áreas adicionales para diseñar el producto correcto.

En este caso, cada una de esas áreas proporciona conocimiento y decisiones claves sobre el mismo, y le ayuda a entender al PO, como gestionar las dependencias, y diseñar estrategias para hacer exitosa la construcción del producto.

El Equipo del Producto

Bajo el contexto anterior en la medida que los productos son más complejos, los PO deben interactuar con más áreas y esas áreas son de contacto frecuente, adicionalmente estas terminan volviéndose lo que en muchos entornos se denomina "El Equipo del Producto".

Este Equipo del producto, debido al rol que desempeñan se podrían definir como son un grupo de personas que  proporcionan información estratégica, táctica, operativa y técnica sobre el producto y que debe ser considerada para la elaboración y refinamiento del Product Backlog.

Este Equipo del producto,es muy probable que:

• sea con el que se realice el Inception y el continuo refinamiento del producto
• tenga un ciclo de reuniones para hablar sobre el producto, su presente y futuro.
• algunos de sus integrantes hagan parte de los stakeholders a los cuales después de cada sprint se presenta incremento del producto cada sprint
• se presenten conflictos entre ellos, pues donde donde hay restricciones y diferentes intereses, lo más natural es que aparezca el conflicto
• tengan necesidades de un facilitador, es decir,  de alguien que les ayude a coordinarse, resolver sus conflictos para no perder su foco. 

El Equipo del Producto ¿Es realmente un equipo?

Lo cierto, es que este Equipo del Producto permanece oculto a la vista de todos, pero es frecuente escuchar por parte del PO, del SM y hasta del Equipo de Desarrollo, quejarse de problemas de:falta de coordinación

• involucramientos tardíos
• falta de compromiso
• conflicto de intereses
• entre otros

Y aunque este grupo de personas tengan un interés común, no implica que se vean como un equipo, pero esto no los exime de las necesidades de que exista un facilitador entre ellos que permita la fluencia de los diferentes temas que ellos tratan. Este rol de facilitador podría ser ejercido por:

• El Product Owner (aunque sería viable por su ubicación estratégica entre el equipo Scrum y los Stakeholders, es probable que no cuente con las habilidades de facilitación)
• El Scrum Master
• El Agile Coach del ecosistema ágil al que pertenece el producto

Este facilitador, determinará si avanza a formarlos como equipo, o los sigue gestionando como un grupo con un interés común.

Unos consejos: Al menos una Sincronización Semanal y una Retrospectiva Mensual

Ahora, sea que ellos se vean o no como equipo, es altamente recomendado:

• Ejecutar al menos una sincronización semanal para identificar avance de pendientes y necesidades de ayuda, esto podría ser apoyado por la gestión visual que proporciona un tablero kanban.  
• Realizar una retrospectiva cíclica, al menos una vez al mes que busque mejorar tanto las interacciones al interior como con el Equipo Scrum.

Estas dos dinámicas serán de gran valor y sumarán bastante a la dinámica de la construcción del producto.

Cerrando

Por último unas preguntas:

• ¿tienes un "equipo del producto"?¿realmente son un equipo?¿les interesa serlo?
• ¿ya lo identificaste?¿o justo ahora te haces consciente de el?
• ¿necesita facilitador?
• ¿podría ser el scrum master del equipo scrum?
• ¿podría ser otro scrum master?¿o un agile coach?
• ¿que cadencia de sesiones tienen?
• ¿sería útil una sicronización diaria, semanal?
• ¿sería valioso tener al menos una retrospectiva mensual para corregir problemas y lograr responder a a las necesidades del equipo scrum?

Hasta acá este compartir, bienvenido el feedback.

Saludos ágiles

Jorge Abad.

Saludos Ágiles
Jorge Abad

Entendiendo el Costo del Retraso - Cost of Delay

Hola a todos

Debido a la explicación recurrente que últimamente hago de este concepto, les comparto esta presentación que me ha ayudado bastante en este propósito

Espero les sirva tanto como a mí.

Entendiendo el Costo del Retraso - Cost of Delay from Jorge Hernán Abad Londoño

Para la comprensión rápida del ejemplo he extraído algunas unas imágenes

------

------

------

------

------

------

------

------

Saludos ágiles

Jorge Abad

Ágil Apestoso (Crappy Agile) vs Ágil de Valor: Una invitación a no perder el foco

Hola a todos

Hace unos días se suscitó en la comunidad de Ágiles Colombia (1) una interesante discusión sobre:

agile (ágil)  = output (entregables o salidas)

agility (agilidad) = outcome (resultados)

Y el punto que quiero compartir es que ágil (agile) nunca ha estado desligado de la generación de valor, ni de los resultados de negocio (outcomes), entendiendo la generación de valor como ingreso y o beneficio para quien lo construye. A continuación comparto dos interesantes definiciones de valor.

Tomado de (2)

Tomado de (3)

Adicionalmente,en el siguiente video de Henrik Kniberg, uno de los referentes en el mundo ágil presenta en el 2012 que un equipo ágil produce salidas (outputs) que deben traducirse en resultados de negocio (outcomes) para los Stakeholders



Si estas salidas que produce el equipo ágil no están orientadas a producir valor, es decir resultados de negocio, estaríamos haciendo

• iteraciones cortas (sprints) para producir desperdicio o software apestoso (en el caso de Scrum y XP) o 
• flujo continuo de software apestoso (aplica tanto para Kanban como para DevOps)

que se vería más o menos así:

No quisiera entrar en discusión si agile (ágil) o agility (agilidad) - no es mi foco en este post -, no, mi punto es que si usted no esta haciendo software de valor que:

• le genere ingresos,
• le reduzca costos,
• le mitigue riesgos o 
• le de más capacidad a su organización,

simplemente esta perdiendo el tiempo, le esta haciendo perder el tiempo a su equipo de trabajo y a su empresa  y está dándole oportunidad a su competencia que lo alcance, lo rebase o le tome más distancia; y considerando los tiempos disruptivos (4) en los que nos encontramos, estos no nos permiten darnos el lujo que antes nos solíamos dar de construir grandes soluciones para luego echarlas a la basura, ¡NO¡, hoy experimentamos rápido, fallamos barato, aprendemos rápido, inspeccionamos y adaptamos, y estamos altamente enfocados en generarle valor al negocio y en consecuencia a nuestros clientes con nuestros productos y servicios.

Mi invitación con este corto post es a que dejes de hacer Ágil Apestoso (o Crappy Agile) y comiences ha realizar Ágil de Valor, tal y como fue definido en el Manifiesto Ágil (5) y tal como lo demandan estos tiempos tan competitivos.


Saludos Ágiles

Jorge Abad

Notas:

• Un saludo especial @MauroStrione a quien recordé mientras hacía este post con su clarla "Ass Driven Organizations"
• Entiéndase que el software de valor requiere de excelencia técnica.

Comentarios, Observaciones y Referencias

1. Meetup Agiles Colombia - https://www.meetup.com/es/AgilesColombia/
2. https://www.scrum.org/resources/blog/agile-value
3. https://jeronimopalacios.com/2016/10/metricas-agiles-fundamentales-ii/ 
4. 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
5. Manifiesto Ágil - https://agilemanifesto.org/iso/es/manifesto.html
6. Software Craftmanship Manifesto - http://manifesto.softwarecraftsmanship.org/#/es

Los ANS y la agilidad

"En muchos casos los ANS (Acuerdos de Niveles de Servicio) parecen estar ahí más para destruir valor que para construirlo

Recomendación:
Vea el ANS como el peor tiempo de su servicio, no como el estándar a cumplir." pic.twitter.com/VR2RXof5wB

— Jorge Hernán Abad L. (@jorge_abad) March 14, 2019

Tweet - Cita sobre Scrum

"Scrum es un buen lugar para empezar pero es un mal lugar para quedarse" @JonKernPA #ScrumDayCo2019 pic.twitter.com/UQ6Hly7NzI

— Jorge Hernán Abad L. (@jorge_abad) March 16, 2019