¿Es la Agilidad solo una moda?

Transformación digital - cortesía de Pixabay

Sin duda hay empresas, y probablemente grandes compañías, para las que la Agilidad es un "moda" a seguir, sellos de certificaciones de calidad y procesos a obtener para poder licitar, o simplemente para practicar el "agilipostureo" y estar "in". En otros casos hay compañías que siguen la "moda" para cumplir con los objetivos estratégicos de transformación ágil, con la idea de que los métodos ágiles aportarán soluciones mágicas a corto plazo que aumenten la productividad de los equipos y bajen los costes... creyendo que eso fuera posible sin cambiar estructura ni cultura.

La Agilidad busca entregar un buen producto además del producto correcto, por tanto en invertir el presupuesto que tenga la compañía de la mejor forma posible... eso suena muy bien y de hecho para muchas compañías construir el producto correcto es una necesidad de supervivencia aunque no sean conscientes todavía. El producto correcto no implica alta productividad, sino en acertar en el producto y que este sea de alta calidad; en otras palabras ser productivos en términos de entrega de valor a nuestros clientes. Y eso sumado a sacar el máximo de las personas que hacen el trabajo, personas motivadas que para hacer cosas serias y grandes disfrutan haciéndolo.

Robot camarero del restaurante
Kyoka en Alcalá de Henares

Una realidad palpable que está ocurriendo en todas las áreas es la transformación digital, el uso de robots combinados con el uso de la internet de las cosas y el aprendizaje automático está cambiando quién hace el trabajo y está cambiando fuertemente el panorama del empleo.

Empleos como cajeros, brokers de seguros, agentes inmobiliarios, analistas de riesgos, asesores de inversiones, periodistas gráficos, reporteros, taxistas, conductores, traductores, personal de limpieza, grabadores de datos, contables, secretarios, trabajadores de fábricas y cadenas de montaje, trabajadores de Servicio al Cliente y muchos más van a ser reemplazados por la automatización.

Por otro lado los empleos que requieran creatividad, inteligencia social y un alto nivel de complejidad o destreza crecerán, como lo son los científicos de datos (big data), los especialistas en inteligencia artificial y aprendizaje de máquinas, los desarrolladores de software y aplicaciones, los analistas, expertos en robótica, en drones y en ciberseguridad, los profesionales de ventas y marketing y otros más.

Por lo tanto los empleos del futuro son aquellos que den respuesta a un mundo donde lo constante es y será el cambio, un mundo donde la incertidumbre es consustancial y la capacidad de adaptarse rápidamente a los cambios que surjan es esencial. Los empleos del futuro son aquellos donde las personas tengan que pensar activamente, innovar y tomar decisiones de forma descentralizada.

Si lo miramos desde la perspectiva del marco de Cynefin vemos que los empleos a desaparecer son los de los dominios simple y complicado, y los empleos emergentes son aquellos de los dominios complejo y caótico.

Personas sobre procesos - cortesía de Pixabay

La Agilidad da solución al dominio complejo, por ejemplo donde con Scrum podemos encontrar prácticas emergentes a problemas adaptativos complejos a través de sus ciclos de inspección y adaptación.

Los trabajos donde no haya que pensar y solo seguir un conjunto de reglas, o se pueda crear un algoritmo que los ejecute, están siendo automatizados y por tanto desaparecerán como empleos. Las compañías automatizables tendrán escasos empleados, la compañías no automatizables, que requieran de adaptación constante y empleados que lidien con el cambio, necesitaran para sobrevivir los valores y principios de la Agilidad. Para estas compañías la Agilidad o Business Agility no será una moda, será un necesidad para poder sobrevivir.

¿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 proveien del pensamiento Lean y 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.

Cortesía de Lean Popup

Un "equipo" con objetivo común

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. Entregas "just-in-time a final" de sprint... o waterfalling.

Thanks to Oliver from Geek & Poke

No es inusual observar gráficos burn-down como los de la imagen de la izquierda, en la que se puede leer que el equipo ha hecho muchas cosas a lo largo del sprint pero no ha acabado nada hasta el final... no ha aprendido a empezar a terminar cosas y a terminar de empezar cosas a nuevas.

Eso puede suele ser por dos razones: el equipo realmente hace waterfalling o no ha aprendido a focalizarse como equipo al completo en una historia de usuario acometiendo las tareas de forma ágil.

6. 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.

Agilidad ≠ velocidad

7. Con Agilidad 9 madres hacen un hijo en 1 mes...

Este chiste refleja uno de los malentendidos más corrientes sobre la Agilidad: el que con métodos ágiles la velocidad de los equipos aumenta mucho.

El malentendido nace de la palabra "ágil", tal como confesó Mike Beedle, quién acuñó el término, hubiera sido más claro utilizar "flexible" y "Flexibilidad".

La Agilidad acelera potentemente la entrega de valor, no porque los equipos desarrollen más rápido, sino porque entregan las cosas correctas que dan solución a las verdaderas necesidades de nuestros clientes.

8. Historias de usuario. Es un chiste tan simple como delicioso :-)

Del post "Historias de usuario, ¿por qué?" de enciendelaluz :-D

---

¡Atención! El siguiente chiste es políticamente incorrecto...

El caballo arrecho, cortesía de Pixabay

9. Van cinco subidos a un caballo y este camina raro. De repente dice el cuarto al quinto, "¡quieres dejar de perculizar al caballo!" y el quinto dice "es que si la saco me caigo"...

Este chiste ilustra de forma políticamente incorrecta, pero muy clarificante, la perspectiva de los desarrolladores de como se sienten y como les entorpece cuando cargan con la estructura empresarial y jerárquica de mando y control en muchas de las realidades de empresas tradicionales.

Recordemos que en Agilidad las personas que realizan el trabajo, y que son trabajadores de conocimiento, deben de ser las que tomen las decisiones frecuentes y las que requieran información local, sean creadores de sus planes y se autoorganicen en equipos. Esto Ilustra la importancia de lideres system-thinkers que apoyen a los equipos en sus decisiones y resuelvan impedimentos sistémicos en sus áreas, lo que probablemente lleve a un aplanamiento o un desescaldado de mando y control en la organización.

Si alguien supiera un chiste relacionado con la Agilidad le invito a añadirlo en los comentarios, mis agradecimientos de antemano.

¿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 en 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 features. Business 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 el 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.