Frase: El mayor riesgo de todos sería no aceptar ninguno

"The biggest risk of all is not taking one." - Mellody Hubson

"El Mayor riesgo de todos sería no aceptar ningunto" - Mellody Hobson

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.

¿Cuándo usar Ágil? o ¿Cuándo se Comienza a Generar Valor un Proyecto Ágil (4)?

Hola a todos

Hace un tiempo vi el excelente video de Agustín Villena - LKES17: Agustin Villena - Alineamiento, flujo y exploración (clic aquí) - recomiendo verlo con papel y lápiz, - por allá en el minuto 16:00-  clic aquí-, comparte la siguente gráfica de Alistair Cockburn.

Develop for business value once risks are down (1)

Donde el mensaje clave es: "Antes de comenzar a generar valor debes bajarle el riesgo a tu proyecto"

Es obvio sino tu proyecto, producto o iniciativa estará torpedeado por impedimentos, retrasos, problemas, desconocimientos, complicaciones técnicas, etc., cayendo en una zona de mucha fricción y poca velocidad en el desarrollo y en consecuencia es difícil generación de valor. Es por eso que también que dentro de las sugerencias para realizar un piloto en ágil se sugiere que la tecnología sea conocida y dominada por el equipo (2).

Ahora también,  lo presenta el articulo de Alistair (1) en el apartado "Don’t confuse knowledge acquisition with BDUF -Big Desing Up Front(3)", es probable que debas asumir una velocidad baja de tu equipo mientras logran:

• entender mejor la arquitectura
• resolver dependencias
• realizar pruebas de concepto
• comprender mejor los frameworks

Y luego de esta zona, si ganar velocidad en la zona de generación de valor.

Hasta acá este cortísimo compartir

Saludos ágiles
Jorge Abad

Referencias, Notas, Aclaraciones y Comentarios

1. Design as Knowledge Acquisition by Alistair Cockbur - clic aquí- .
2. Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos. - clic aquí -.
3. Big Desing Up Front: the old habit of sitting at the desk and drawing up a big, fancy, full-scale design (BDUF = “big design up front”) (1)
4. Cada vez más me alejo del concepto de Proyecto Ágil, podria cambiar este título por ¿Cuándo se Comienza a Generar Valor en la Construcción de un Producto de Forma Ágil?

[notas Agiles2014] Sobre el riesgo en proyectos ágiles

Nota introductoria: con este tag [notas Agiles2014] pondré las notas y el resumen de lo que aprendí en el pasado Agiles2014 - realizado en Medellín-Colombia.

Le pregunte a Bob Galen y a Ángel Medinilla sobre la gestión de riesgos y las respuestas fueron - palabras más palabras menos -  las siguientes:

Bob Galen

• En ágil no hacemos gestión del riesgo, reaccionamos y nos adaptamos a los eventos, si algo cree importante el product owner sobre lo que se tenga que tener cuidado pues lo pondrá en el product backlog.

Ángel Medinilla 

• En ágil no podemos ignorar el riesgo, es cierto reaccionamos a los eventos - inspeccionamos y nos adaptamos - , pero no podemos ponernos como en el PMI a realizar una lista de todos los riesgos, pero si algo es un riesgo y es casi un evento inminente se deberá ayudar al product owner a priorizarlo en el backlog para que se trabaje en esto. Ángel me decía que si en 7 meses es la integración con SAP no podemos esperar los 7 meses para ver como reaccionamos, debemos poner en algún momento tareas técnicas en el Product Backlog para que esta integración no nos coja de sorpresa.

Me gusta más la respuesta de Ángel.

Cada cual saque sus conclusiones

Saludos ágiles

Jorge Abad 

Scrum: Hoja del Sprint y los Riesgos

Una de las características de scrum y de las metodologías ágiles es la importancia que se le da a la visualización de información o radiadores de información, esto no implica que no haya seguimiento y elementos digitales pero se le da prelación a lo visual (preferiblemente papel) esto logra:

• compromiso del equipo 
• información instantánea (no se requiere ingresar a url para saber algo)
• el equipo sabe el status del compromiso en el Sprint y en el Release de manera constante.
• se visualiza la deuda técnica
• se observan los bugs y problemas que han habido durante la construcción del producto
• se visualiza la velocidad a través de los sprints.

Una de los elementos radiar es la "Hoja del Sprint" o "Página de Información del Sprint" la cual cuenta con los campos:

• Nombre del equipo
• Nombre del producto
• Número del Sprint
• Objetivo del Sprint
• Pila del Sprint (debe estar en orden, arriba las historias mas prioritarias con su respectivo puntaje)
• Velocidad estimada
• Calendario (fecha y lugar de la diferentes reuniones)
• Daily
• Refinamiento
• Review
• Retrospectiva
• Equipo (cada miembro con su dedicación)
• Product Owner (PO)
• Scrum Master (SM)
• Cada miembro del team developer 

Un campo adicional que he observado que sirve a todo el equipo de Scrum (PO, SM y Team Developer) para poner atención a los elementos que pueden hacer fracasar el sprint, es el de RIESGOS.

La idea es poner este campo con los posibles riesgos priorizados que afectan al sprint y las historias que estan siendo afectadas por este riesgo en caso que aplique, por ejemplo:

• Riesgos
• No se llegue a un acuerdo sobre los campos (afecta historia: Depósito)
• La migración no sea "transparente" (afecta historia:  Herramienta migración)

Aunque una cosa es cierta, el SM y todo el equipo deben procurar que al sprint no se entren historias con riesgos que hagan "caer" el sprint y los puntos comprometidos (por lo general se usa un SPIKE, que es una historia con TIMEBOX y salidas definidas que permiten resolver los riesgos durante un sprint anterior, ejemplo: "realizar pruebas de concepto de la migracion",valor asignado 2 puntos). Si inevitablemente se debe entrar al sprint con riesgos, la visualización de los mismos hace parte de una buena gestión de impedimentos en cabeza SM y de todo el equipo Scrum.

De todos modos, no se debe perder la oportunidad de la retrospectiva para aprender si fue efectiva o no la gestión de riesgos y los resultados obtenidos por permitir su ingreso al sprint.

Saludos ágiles

Jorge Abad

[1] Scrum y XP desde las trincheras - http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf

_

Scrum: La Reunión de REFINAMIENTO, clave para reducir Riesgos y reducir tiempo del Sprint Planning

El refinamiento aunque no es una de las reuniones oficiales de Scrum [1], si se dice que el 10% del sprint debería dedicarse a esta actividad.

Dice la guia [1]:

"El refinamiento (refinement) de la Lista de Producto es el acto de añadir detalle, estimaciones y
orden a los elementos de la Lista de Producto. Se trata de un proceso continuo, en el cual el
Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos
de la Lista de Producto. Durante el refinamiento de la Lista de Producto, se examinan y revisan 
sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente 
consume no más del 10% de la capacidad del Equipo de Desarrollo. Sin embargo, los elementos
de la Lista de Producto pueden actualizarse en cualquier momento por el Dueño de Producto o a
criterio suyo."

Bajo este escenario la duración de la reunión de refinamiento debería ser:

	Duración máxima de la reunión en horas
Tamaño del Sprint	1 Semana	2 Semanas	3 Semanas	4 Semanas
Refinamiento	1	2	3	4

Si lo miramos bien toma un tiempo considerable del sprint (aunque he experimentado en sprints de 2 que semanas 4 horas son suficientes),  tal vez se haga en una sola sesión o en varias según el caso, pero una de las ideas claves de scrum es:

"tengamos las reuniones suficientes de manera que no sea necesario hacer más reuniones, y podamos enfocarnos en lo que nos gusta, la construcción del producto."

.

Lo cierto es que esta actividad tiene grandes beneficios tanto para el sprint que viene, como para la construcción del producto.

Esta reunión (no-oficial) de scrum tiene como objetivo, presentar los próximos ítemes de backlog al equipo que van a entrar tanto para el siguiente sprint como para los 2 o tres próximos y discutir aspectos sobre ellos. Una de las agendas que he empleado en los refinamientos es la siguiente:

1. Lectura y estimación de las historias de usuario que posiblemente entran en el PRÓXIMO SPRINT. Se leen las historias de usuario con sus criterios de aceptación, se realiza la conversación, entendimiento y ajuste sobre las mismas.
2. Lectura de historias de usuario (no al detalle, solo el título de las mismas) que entrarán en los próximos  2 ó 3 sprints
3. En equipo se identifican los insumos requeridos para estas historias tanto desde el punto de vista de conocimiento como de entes externos al equipo (otras áreas, otros proveedores, etc)
4. En equipo se identifican los riesgos que pueden hacer que esas historias no se completen y se identifican actividades a realizar para mitigarlos.

De este manera:

• El Scrum Master y el Product Owner (y en ocasiones el Team Develper) comienzan a trabajar conjuntamente en la resolución previa de:
• riesgos
• insumos 
• e impedimentos
• El equipo conoce que viene para el próximo sprint
• El planning es una reunión mas liviana donde se presentan los aspectos modificados o afinados de las historias de usuario y algún cambio en la priorización.
• Todo el Equipo Scrum (Product Owner, Scrum Master, Team Developer) van observando como se va construyendo la visión del producto y se pueden alinear desviaciones.

Saludos ágiles

Jorge Abad.

Referencias

[1]Scrum Guides - https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf#zoom=100

Tiempos máximos de las reuniones de Scrum según el tamaño del Sprint

Hola a todos

A continuación relaciono el tamaño máximo de las reuniones de Scrum, según el tamaño del sprint. Estos tiempos fueron extraídos de la guía de Scrum [1]:

Tamaño del Sprint	1 Semana	2 Semanas	3 Semanas	4 Semanas
	Duración máxima de la reunión en horas
Sprint Planning	2	4	6	8
Sprint Review	1	2	3	4
Sprint Retrospective	0,75	1,5	2,25	3
Daily (15 minutos)	0,25	0,25	0,25	0,25
Refinamiento (tiempo máximo)	4	8	12	16

La idea es que estos  tiempos se respeten, logrando el TIMEBOX o tiempo asignado para el objetivo defnido.

Es importante resaltar los siguientes aspectos:

• El Scrum Master como dueño del proceso, es responsable de que estos tiempos no se superen.
• Los primeros 2 o 3 sprints es muy probable que no se cumplan con los TIMEBOX, pero se debe trabajar en equipo y en la retrospectiva buscando la causa y las acciones a realizar para que esto no se repita. 
• Los únicos TIMEBOX que desde el inicio se deben respetar son:
• Daily = 15 minutos
• Duración del Sprint = la definida (no se sugiere estar cambiando la duración de sprints, se debe buscar trabajar a un ritmo regular y constante)

Saludos ágiles
Jorge Abad.

Referencias

[1]Scrum Guides - https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf#zoom=100

Continuidad en la evaluación de los riesgos

¿ya identificaste todos los riesgos con su impacto?

en serio..¿ya identificaste todos los riesgos con su impacto? 

insisto ¿ya identificaste todos los riesgos con su impacto?  

-


---
¿y le hiciste seguimiento a los identificados?




_