domingo, 18 de agosto de 2019

¿Un par de chistes relacionados con la Agilidad?

Thanks to Oliver from Geek & Poke
Hay algunos chistes que tienen que ver con la Agilidad, o sus disfunciones, y que me han hecho mucha gracia y que he decidido compartir en este post.

1. DoAD. La imagen la izquierda, una disfunción clásica: DoAD o definición de casi hecho, que a veces también se presenta como DoD seguido de DoDD; cuando finalmente está "done done".

Hay que comprender que si queremos ser ágiles y poner nuestro foco en generar valor este solo está presente en una funcionalidad si esta está acabada al 100%, sino simplemente no está, una funcionalidad acabada al 99% tiene valor = 0. Una de las lecciones más difíciles para algunas compañías es aprender a permitir que sus equipos encuentren el ritmo en el que sprint a sprint entreguen funcionalidades acabadas al 100%.

2. Ante un vaso medio lleno algunos lo verían medio lleno y otros medio vacío, pero, ¿qué diría un Scrum Master? ... pues preguntaría ¿porqué el vaso es tan grande?

Este chiste me encanta ya que pone foco en las dos características clave de un Scrum Master: las personas y el proceso. Desde la perspectiva de las personas con un vaso más pequeño todo el mundo lo vería lleno, lo que se puede traducir en un aumento de motivación, y desde la perspectiva del proceso un vaso demasiado grande es puro desperdicio o muda.

3. ¡Jajaja, tu lado del barco tiene un agujero!

Muchas veces confundimos un equipo con un grupo de trabajo, un equipo integrado tiene un objetivo común por el que todos van a "muerte". Este chiste ilustra la disfunción clásica de supuestos equipos en los que podemos escuchar frases como "esta no es mi tarea" o "a mi no me pagan para hacer esto"...

4. El problema de los post-its es que se caen a los seis meses.

Este chiste ilustra disfunciones como el agilipostureo y la ignorancia, utilizar post-its por razones que nada tienen que ver con la Agilidad. Si un equipo trabaja con Scrum y hace sprints de digamos dos semanas, sus post-its tienen una vida de dos semanas, no se van a caer. En ambientes escalados la vida de un post-it seria cómo máximo de 3 meses. Si los post-its se caen a los seis meses es que no hay cadencia, seguramente se trate de un waterfalling encubierto.

5. Un desarrollador aprende a disparar y no hay manera de que acierte en la diana, y dice: "desde mi punto la bala ha salido, si no ha llegado debe de ser problema de la diana".

Este chiste es tan sutil como real, ¿cuántas veces los desarrolladores desconocen de qué forma parte el código que escriben? ¿y lo que escriben otros con los que están directamente relacionados? A veces su visibilidad es solo sobre sus tareas particulares, quizá hasta QA, donde puede que desconozcan las pruebas que se aplicaran a su código... por no hablar de los despliegues de su código que hacen terceros de forma independiente. Es como intentar acertar en una diana que no ves y todo tu foco está en la tarea, en disparar la bala.

También es un chiste disfuncional de DevOps, con DevOps un desarrollador tiene visibilidad y responsabilidad hasta el mismo despliegue en producción, es el responsable directo de la calidad de lo que se despliega, y eso fomenta y crea compromiso.

6. Historias de usuario. Es un chiste tan simple como delicioso :-)
Del post "Historias de usuario, ¿por qué?" de enciendelaluz :-D
Si alguien supiera un chiste relacionado con la Agilidad le invito a añadirlo en los comentarios, mis agradecimientos de antemano.

miércoles, 7 de agosto de 2019

¿Cuál podría ser una agenda de una PI Planning?

La PI Planning, usualmente en un entorno trimestral, sirve para la sincronización y alineamiento entre equipos, con negocio y con sistemas/arquitectura. Es una reunión abierta donde todos los interesados (negocio, sistemas, ...) y miembros del tren (ART) comparten información y se coordinan con la idea de reformular la visión, planificar el siguiente trimestre y obtener feedback sobre cómo están funcionado las cosas.

Una agenda resumen de lo que ha sido exitoso en mi experiencia sería algo así:
Agenda de una PI Planning con los puntos a tratar y quienes intervienen en cada paso - gracias Ángel por la foto
Día 1

7:30 - 8:00 Café y desayuno
Un café con desayuno tiene dos bondades, primero atrae, en nuestra cultura española es signo de relevancia, y segundo despierta nuestras mentes y nos predispone a ser más abiertos de mente. 

8:00 - 9:00 Contexto de negocio
¿Cuantas veces hemos oído a los miembros de los equipos interesarse por los valores y la dirección de la empresa? No sobre informes de éxitos y ventas en el último año, sino sobre el propósito de la empresa y sobre su futuro. Es la ocasión ideal para que el CEO o un directivo dé una primera introducción poniendo contexto de negocio al trimestre junto al mensaje "¡esto va en serio y tenéis todo nuestro apoyo!".

9:00 - 10:00 Visión del producto y top features
¿Cuántas veces hemos visto como los desarrolladores de software codifican software en base a tareas aisladas y no entienden de lo que forma parte su trabajo? Los jefes de proyecto se quejan de trabajo duplicado y de decisiones desafortunadas que éstos toman. Esta es la ocasión ideal para hacer que todos se sientan parte de algo más grande, el producto o proyecto. Product Management expone la visión con los grandes rasgos del producto a construir y los principales objetivos de negocio a dar solución en el trimestre. Los miembros de los equipos así comprenden de qué forman parte y tomaran mejores decisiones en la construcción del software.

10:00 - 11:00 Visión de arquitectura y UX
Si queremos dar verdadera guía arquitectónica, de UX y sobre el contexto tecnológico, es responsabilidad de arquitectura, UX, sistemas y líderes técnicos comunicar, y con comunicar quiero resaltar que se trata de hacer entender y dar las herramientas necesarias para que los equipos de desarrollo se alineen y construyan eficientemente.

11:00 - 11:30 Descanso con icebreaker y café
Los icebreakers tienen la bondad de energizar a los asistentes, de darles ocasión de divertirse y conectar con los demás y sentirse más despiertos. Estos junto a un momento de distensión con un buen café prepara a los equipos para su primera sesión de trabajo.

11:30 - 12:00 Contexto del evento
El RTE, el coach ágil, expone el objetivo principal de la PI Planning, presenta la agenda y explica el funcionamiento de la misma.

12:00 - 15:00 Primera sesión equipos (breakout)
En la fase preparatoria se han distribuido tableros y post-its en áreas de trabajo independientes para cada equipo. En este paso los equipos dividen features en historias de usuario e historias técnicas (enablers) y las planifican a modo de borrador en los sprints del trimestre. También identifican sus objetivos para el trimestre, y toman nota de dependencias y riesgos que detecten.

Las dependencias que hayan emergido las resuelven con los otros equipos, si estos están e la sala, para luego ajustar las historias de usuario en los sprints en consecuencia. Principalmente son las dependencias resueltas las que  determinan el orden de ejecución de las historias, estas se recogen en program board junto a las features.

15:00 - 16:00 Comida
La comida es la ocasión ideal para que la gente hablé de niños, fútbol y toda clase de temas terrenales y que se forjen relaciones y confianza. La comida es especialmente útil en caso de equipos deslocalizados, una ocasión para crear conexiones entre las personas de diferentes localizaciones y para potenciar su colaboración.

16:00 - 17:00 Revisión de los borradores de la planificación
De vuelta a la PI Planning los equipos presentan sus planes individuales a todo el tren, uno por uno exponen sus objetivos, capacidad, riesgos detectados y dependencias resueltas. No se muestran historias de usuario, lo importante es exponer qué objetivos de negocio se resuelven con estas.

17:00 - 18:00 Revisión de managers
Business Owners, Product Managment, RTE, arquitectos y otros líderes y directivos han recibido un plan impregnado de realidad que probablemente no cuadre al 100% con sus deseos expresados mediante las features... es un momento de aprendizaje sobre lo que es factible y decidir que hacer para el segundo día de la PI Planning.

Día 2

7:30 - 8:00 Café y desayuno
Ocasión ideal para que los asistentes reconecten de nuevo y esté preparados para afrontar el día con energía y proactividad.

8:00 - 9:00 Ajustes para los planes
En base a lo que los managers hayan aprendido sobre la factibilidad éstos devuelven a los equipos ajustes como cambios en la visión, variación en las prioridades de negocio y movimientos de personas y de recursos. 

9:00 - 11:00 Segunda sesión equipos (breakout)
Segunda sesión de trabajo en la que los equipos hacen ajustes en sus planes, Business Owners les habrán marcado valor de negocio a sus objetivos para que les sirva de guía, siguen resolviendo dependencias y detectando riesgos.

11:00 - 11:30 Descanso con icebreaker y café
Momento necesario para descansar y reponer energías.

11:30 - 12:30 Revisión de los planes finales
Después de una segunda revisión probablemente los planes individuales de los equipos se hayan acercado lo suficiente al deseo expresado por las top featuresBusiness Owners aceptan los planes y dan su visto bueno, si no fuera el caso habría que retrabajar.

12:30 - 13:30 Gestión de riesgos
Antes de llegar a la fase final se tratan los riesgos detectados por los equipos que afecten al tren: cada uno de ellos se clasifica según una matriz ROAM (Resuelto, Asignado gestor - Owned, Aceptado y Mitigado).

13:30 - 14:00 Voto de confianza
Con una técnica muy simple, levantando en el mismo instante una mano con 1 a 5 dedos extendidos (desde 1 que significa sin confianza en el plan a 5 que significa un plan perfecto), todo el mundo da feedback de su nivel de confianza en el plan obtenido. Todos han participado durante dos día en el evento, todos deberían de estar convencidos de que plan funcionará, y si hubiera alguien que no confiara deberemos aclarar sus preocupaciones antes de empezar el PI.

Si el voto de confianza indica un buen plan
Se han podido aclarar y resolver las preocupaciones de quienes hayan levantado 1 y 2, si es que los ha habido.

14:00 - 15:00 Retrospectiva sobre todo el evento
Con espíritu de mejora continua la PI Planning termina con una retrospectiva ligera. En tres tableros con tres temas, lo que ha ido bien, lo que no y lo mejorable, se recogen ideas que finalmente cada asistente puede votar, usualmente con 3 palitos o estrellitas a repartir libremente. La idea es recoger feedback que RTE con Scrum Masters trataran durante el PI para la siguiente PI Planning.

15:00 - 17:00 Comida con cervezas para team-building
Una buena sesión de PI Planning se merece un buen manjar y que el CEO o directivo invite a cervezas ;-)

Si el voto de confianza indica que hay que retrabajar el plan
Las preocupaciones han levantado temas de mayor calibre que hay que despejar antes de seguir, una posible agenda podría ser la siguiente:
Quiero aprovechar el post para agradecer al grupo de RTEs lo
mucho que he aprendido de ellos :-) Thanks! Alexey, Yann,
Guy-Alexandre, Denis, Matt, Alex, Lionel, Sébastien y Benoît

14:00 - 15:00 Retrabajo
15:00 - 16:00 Comida
16:00 - hh:00 Retrabajo
hh:00 - hh:30 Voto de confianza
hh:30 - Retrospectiva sobre el evento

Pudiera ocurrir que aún con retrabajo un nuevo voto de confianza indicara que el plan no fuera factible. En ese caso hay que parar, escalar, averiguar causas raíz, resolver y planificar una PI Planning posterior. Para que un PI tenga éxito y se produzca la mejora continua no podemos empezar en ningún caso en falso, estamos hablando que 100 personas pueden fallar y eso no debemos de permitirlo.