domingo, 22 de septiembre de 2019

¿Hay alguna actividad que permita sentir como ha de ser un líder al servicio?

Actividad para sentir lo que es un líder al servicio
Una de las transiciones que requieren las transformación ágiles es que los directivos y mandos intermedios transicionen de jefes con mando y control a líderes al servicio del sistema del que están a cargo, en concreto a líderes de sus empleados, las personas que componen el sistema.

Los directivos tradicionales están entrenados para tomar decisiones principalmente en base a informes con números y gráficos. El liderazgo al servicio requiere contar con las personas que realizan el trabajo, requiere desarrollar la inteligencia emocional necesaria para un liderazgo eficaz. Este post pretende mostrar una actividad que puede ayudar a los directivos a sentir y comprender lo que necesitan para liderar a las personas con las que trabajan.
Suelo con vasos, en este ejemplo vacíos
La idea es muy sencilla; en una sala colocamos en el suelo una población densa de vasos de plástico, al futuro líder al servicio se le vendan los ojos y uno o varios empleados le guían a través de la maraña de vasos de un extremo al otro de la sala.

Los vasos pueden estar vacíos o llenos de agua, si llevan agua añaden un poco más de emoción a la dinámica, ya que así creamos un peligro real, aunque nimio, de mojarse los zapatos y por ende los pies.

La experiencia del directivo comienza con sentir que depende totalmente de las personas que le guían, se sentirá más o menos seguro en función de qué y como le expliquen; si le explican lo que le rodea, como es la sala, como son los vasos y como están espaciados hará que sienta confianza y seguridad. Aquí hay una primera lección; si queremos personas seguras e implicadas necesitamos explicarles el contexto de negocio y de su trabajo. Los empleados no tienen la visión global de la compañía y el sentirse parte de esta va a depender de la destreza de los lideres de comunicarla.
Empleados guiando a su líder

Como tienen los ojos vendados no les queda otra que confiar en quienes les guían, al principio se sentirán nerviosos pero a medida que avancen por la habitación sentirán que pueden confiar en sus guías. Aquí hay una segunda lección; dáles confianza y autoridad a su nivel a tus empleados. Costará al principio, puede ser un cambio contra el que se revelen partes de ti, pero verás que funcionará y te sentirás aliviado y orgulloso de la gente con la que trabajas.

Y una ultima lección para los líderes es el empatizar con los empleados, el poder sentir lo que sienten ellos en sus interacciones diarias y aprender del famoso refrán "no hagas a los demás lo que no quieres que te hagan a ti".

Para llevar la actividad a un siguiente nivel se intercambian los roles. Los empleados se tapan los ojos y son los líderes los que tienen que guiarlos en el recorrido de la sala para que no tropiecen con ningún vaso (si son muchos puede hacerse por rondas para que cada empleado pueda experimentarlo). Con esta parte de la actividad lo que se busca es que los líderes sientan, de una manera real, la responsabilidad de liderar a otros de una forma efectiva, comunicándose de manera directa y continua teniendo que ganarse la confianza de las personas a las que lidera.

A su vez esta parte del juego sirve para que los empleados empaticen con sus líderes y sientan en primera persona lo que significa liderar a otros, siendo esta una poderosa herramienta para que puedan comprender mejor muchas de las razones de sus acciones. ¡¡¡Empatia a tope!!!

martes, 17 de septiembre de 2019

¿Cuál es la forma mas sencilla de escalar?

Thanks Daniel for explaining SAFe news :-)
Recientemente organizamos un meetup que llamamos SAFe Talks & Beers - Transformación Agile con SAFe aprovechando que el partner manager Emea de SAFe®, Daniel Boudier, pasaba por Madrid y le invitamos para que hablara de las novedades de SAFe.

En la sesión de preguntas y respuestas alguien hizo esta pregunta, se refería a una transformación Lean-Agile, y me lancé a contestarla... la respuesta la tenia allí, ante mi; ¡aquí la tenéis!, respondí, señalando al Big Picture de SAFe.

Big Picture de SAFe
Lo primero que me vino a la mente es que cualquier marco escala igual de mal, es difícil y complejo escalar manteniendo los valores y principios ágiles, y aún más si vamos más allá de los 125 individuos. Por otro lado tenía claro que las empresas españolas que pueden ser Agile ya lo son, a las demás creo que podemos ayudarles a mejorar sus formas de trabajar convirtiéndolas en mejores lugares de trabajo y aumentar la entrega de valor, aunque también creo que les queda un largo camino, si es que alguna vez llegan a ser Agile.

¿Porqué reinventar la rueda? ¿Cómo evitar nuestros impedimentos sistémicos? Pues ahí está SAFe, una solución compleja a un cambio complejo como lo es una transformación Lean-Agile, o un escalado en una compañía en vías de transformación. Eso convierte a SAFe en la forma mas sencilla para empezar a escalar. Probablemente las soluciones que aporte no sean las idóneas para la empresa, pero son un punto de partida Agile, probablemente las mejores de las que disponemos.

La mejora continua se encargará de llevarnos a las mejores prácticas idóneas para la compañía. Como nos dice Tom Peter: "Las empresas excelentes no creen en la excelencia, sino en la mejora continua y en el cambio continuo".

Mi respuesta puede haber sido mas o menos popular, lo cierto es que coaches ágiles apasionados en mejorar la forma de trabajar de las personas harán que ocurra el escalado con éxito, y con conocimiento de SAFe pueden tener todos los ingredientes para dar un primer paso, para que todos en la compañía en transformación estén alineados, tengan la misma visión y se sientan motivados.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

domingo, 15 de septiembre de 2019

¿Cúal es la importancia de formación en una transformación Lean/Agile con SAFe®?

La formación es fundamental para que todos los participantes de una transformación Lean-Agile comprendan los valores, principios ágiles y prácticas del marco de SAFe®, así como que entiendan sus nuevas funciones y responsabilidades. De esta manera garantizamos que todo el mundo juegue con las mismas reglas, esté alineado con la transformación y tenga expectativas similares. La formación proporciona a todo el mundo la visión de hacia donde se dirigen las nuevas formas ágiles trabajar de la compañía, les hace sentir partícipes y estar comprometidos.

Al tratarse de trenes (ARTs) de más de cien personas, personas que hay que formarlas a todas sin excepción cada una en su rol, sin formación una transformación Lean-Agile se vuelve muy costosa y se alargará en el tiempo, desmotivando y produciendo muchos altibajos. Recordemos lo que nos dice Derek Bok: "Si crees que la formación es cara... prueba con la ignorancia".

Veamos a continuación como SAFe aborda una transformación Lean-Agile, fijémonos en todos los puntos en los que la formación es clave:
SAFe Implementation Roadmap - imagen cortesía de © Scaled Agile, Inc.

Para que haya un "Go SAFe" es necesario que el CEO o el comité estratégico reciba previamente formación de SA (SAFe Agilist), o de SGP (SAFe Government Practitioner) en caso de empresa pública, para comprender en qué consiste la transformación y tomar la decisión con conocimiento de causa y estar preparado para liderarla.

Decidida la implantacion de SAFe hay que identificar a aquellas personas que vayan a ser los agentes del cambio o coaches, y que junto con la dirección vayan a liderar la transformación; estos agentes del cambio deberán de formarse en SPC (SAFe Program Consultant).

Para garantizar el éxito lo más pronto posible hay que formar a todos los directivos y mandos intermedios en SA (SAFe Agilist), ellos son los que pueden impulsar y acelerar la transformación en toda la compañía.

Para preparar el lanzamiento del primer tren es necesario formar a todos los interesados en SA (SAFe Agilist), a los Propietarios del Producto y Product Managers en POPM (SAFe Product Owner/Product Manager), a los arquitectos en ARCH (SAFe Architect), a los Scrum Masters en SSM (SAFe Scrum Master) y, justo antes de la primera PI Planning, a todos los equipos de desarrollo en SP (SAFe Practitioner).

A lo largo de la ejecución del primer PI, y como parte de la mejora continua, podemos formar a los equipos en técnicas de desarrollo ágiles con ASE (SAFe Agile Software Engineer), y junto con sistemas, en SDP (SAFe DevOps Practitioner).

Lanzado el primer tren con éxito podemos potenciar la mejora continua en diferentes frentes: el enfoque de producto con APSM (SAFe Product and Solution Manager), evolucionar al RTE con RTE (SAFe Release Train Engineer), mejorar las habilidades de coaching de los Scrum Masters con SASM (SAFe Advanced Scrum Master) e implementar la capa de portfolio con LPM (SAFe Lean Portfolio Manager).

A continuación una introducción a los diferentes curso que aseguran una implementación de SAFe exitosa:

Leading SAFe - Certified SAFe® Agilist
Curso que cubre todo el marco y que enseña los principios y prácticas de SAFe, así cómo entregar valor a través de grandes equipos de equipos, los trenes o Agile Release Trains, y lo que significa liderar una transformación Lean-Agile a escala de compañía.

SAFe for Government - Certified SAFe® Government Practitioner
Curso que enseña los principios y prácticas de Scaled Agile Framework (SAFe), cómo ejecutar y entregar valor a través de Agile Release Trains, y lo que significa liderar una transformación Lean-Agile de un programa dentro de una empresa pública.

Implementing SAFe - Certified SAFe® Program Consultant
Curso para los agentes del cambio que implementan y aplican Scaled Agile Framework (SAFe) como parte de una transformación empresarial Lean-Agile. Proporciona los conocimientos necesarios para comprender y liderar la transformación dentro la una organización tomando como referencia las pautas y herramientas proporcionadas por SAFe.

Lean Portfolio Management - SAFe® Lean Portfolio Manager
Curso que enseña a capturar el estado actual y futuro de la cartera en el Portfolio Canvas, a diseñar un flujo de cartera mediante un Kanban, a priorizar las iniciativas estratégicas maximizando el valor y beneficio económico distribuyendo el presupuesto de manera Lean asegurando así invertir de la mejor manera posible y mediante guardarailes.

Agile Product and Solution Management - SAFe® Product and Solution Manager
Curso que enseña a definir una visión, estrategia y hoja de ruta para acceder a nuevos mercados. Mediante el feedback rápido se aprende a construir productos y soluciones excepcionales que están alineados con la estrategia, cartera, arquitectura evolutiva e intención de solución de la organización.

SAFe Product Owner/Product Manager - Certified SAFe® Product Owner/Product Manager
Curso para desarrollar el conjunto de habilidades necesarias para guiar la entrega de valor en una empresa y aprender sobre las actividades, herramientas y mecanismos utilizados para administrar las pilas y los programas.

SAFe Scrum Master - Certified SAFe® Scrum Master
Curso que explora el rol de Scrum Master en el contexto de los componentes clave de Agile en el desarrollo a escala a nivel de compañía. Prepara a los asistentes para planificar y ejecutar junto al RTE con éxito las planificaciones en ambiente trimestral, las PI Plannings.

SAFe for Architects - Certified SAFe® Architect
Curso SAFe para arquitectos que prepara estos para participar en toda la organización como líderes al servicio y agentes de cambio. Enseña los roles, las responsabilidades y la mentalidad de los Agile Architects, para que aprenden a alinearse con el valor de negocio e impulsar el flujo continuo en grandes sistemas de sistemas mientras apoyan la ejecución del programa SAFe.

SAFe for Teams - Certified SAFe® Practitioner
Curso para desarrollar las habilidades necesarias para convertirse en un miembro de equipos de alto rendimiento de un Agile Release Train, y aprender a cómo colaborar de manera efectiva con otros equipos. Cubre los marcos de Scrum, Kanban y el nivel de programa de SAFe.

SAFe DevOps - Certified SAFe® DevOps Practitioner
Curso para desarrollar una comprensión del flujo de valor que se inicia con la Exploración Continua, pasa por la Integración Continua, el Despliegue Continuo y los Lanzamientos a Demanda. Los asistentes exploran el enfoque CALMR de SAFe para DevOps, que crea una cultura de responsabilidad compartida para todo el espectro de entrega de soluciones.

SAFe Agile Software Engineering - Certified SAFe® Agile Software Engineer
Curso que enseña prácticas que permiten el flujo continuo de entrega de valor y calidad de desarrollo. Incluye técnicas XP como TDD (Test Driven Development) y BDD (Behavior Driven Development). Estas consisten en prácticas probadas para detallar, modelar, diseñar, implementar, verificar y validar el uso de funcionalidades a lo largo de la Continuous Delivery Pipeline.

SAFe Release Train Engineer - Certified SAFe® Release Train Engineer
En este curso se explora y enseña las habilidades necesarias para facilitar y habilitar la entrega de valor de principio a fin a través de trenes o Agile Release Trains de alto rendimiento a través del liderazgo al servicio y el coaching del rol del RTE.

SAFe Advanced Scrum Master - Certified SAFe® Advanced Scrum Master
Curso que cubre la facilitación y coaching de interacciones entre equipos para apoyar la ejecución del programa y la mejora continua. Mejora el paradigma de Scrum con una introducción a la ingeniería escalable y las prácticas de DevOps, así como la aplicación de Kanban para facilitar el flujo de valor.

Como Gold Partner de Scaled Agile impartimos en Estratecno todos estos cursos de SAFe y ofrecemos servicios de acompañamiento en la implantación de una transformación ágil con SAFe.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

martes, 10 de septiembre de 2019

¿Se deben de estimar los bugs?

Bug de software - cortesía de Pixabay
Esta cuestión genera mucho debate ya que solemos considerar los bugs como algo negativo, algo que asociamos a un error humano y que tiene coste para la empresa, y en ambientes tradicionales hasta pueden ser elemento de penalización.

La perspectiva ágil de los bugs es entender en primer lugar que no existe software libre de bugs, y que estos son desperdicio que supone una oportunidad de aprendizaje para la mejora continua de la construcción del software. Debemos de ir a la causa raíz del bug, probablemente esté relacionado con un impedimento sistémico, y resolverla con técnicas como XP, formación, coaching o técnicas de DevOps.

Veamos lo que nos dice la Scrum.org al respecto de la gestión de bugs: "A menos que su empresa tenga una guía específica sobre la corrección de bugs, representan trabajo a realizar, y el Propietario del Producto debe incluirlos y priorizarlos en la pila del producto. Hay dos excepciones; si el trabajo para corregir el bug es menor que el trabajo para registrarlo, y si el bug es tan crítico que sería negligente dejarlo sin corregir."

A esto podemos añadir:
  • Si el bug se descubre durante el sprint y se refiere a una historia de usuario de la pila de sprint en curso, este se corrige directamente. La corrección del bug forma parte del trabajo del sprint, probablemente el incremento no se pueda considerar hecho y por tanto no sería potencialmente desplegable en producción.
  • Si el bug se descubre fuera del sprint, viene de una historia de usuario de otro sprint, entonces, tal como nos dice la Scrum.org "si el bug es menor que el trabajo para registrarlo o si el error es tan crítico que sería negligente dejarlo sin reparar" se corrige directamente.
  • Si el bug se descubre fuera del sprint, quizá hasta ya esté en producción, y no es crítico, y por tanto se resolverá en un sprint futuro este debe de incluirse en la pila del producto como historia técnica.
Para concluir, si el bug ha generado un elemento en la pila de producto, no importa si es un bug o un cambio funcional recientemente identificado, este debe de ser estimado para que el Propietario del Producto lo priorice adecuadamente y el equipo de desarrollo pueda planificar el sprint en donde se vaya a corregir.

Una empresa puede tener una política específica para la corrección de bugs. Es habitual la reserva de capacidad, o capacity allocation, en la que se reserva un porcentaje de tiempo de los sprints para corregir bugs y otras historias técnicas. En este caso no se estiman los bugs, éstos se priorizan adecuadamente y se corrigen tantos bugs como sea posible en el sprint durante ese timebox .

lunes, 9 de septiembre de 2019

¿Existe un Manifiesto Ágil para coaches ágiles?

Cortesía de los autores firmantes del manifiesto,
declaran que este es un regalo para uso de todos
Inspírese - https://agilepeoplemanifesto.org/
En junio de 2019 19 agilistas de 15 países de todo el mundo crearon en Smögen, Suecia, el Agile People Manifiesto, o Manifiesto para Gente Ágil, un regalo para todo agilista para que lo use y se inspire.

Reformulando la frase de Peter Stevens: "Yo creo que Scrum, Agile y Lean Startup están transformando el mundo del trabajo. Creo que la gente apasionada dará lugar al cambio. Mi objetivo como coach ágil es ayudar a descubrir Scrum y cómo puede ayudarle a transformar su mundo".

Este manifiesto es para estas personas apasionadas, está compuesto por 7 valores a los que todo coach ágil debería de suscribirse desde su corazón y forma de proceder:
AgilePeopleManifesto
  • Las personas ágiles son curiosas y colaboran para crear un valor increíble y soluciones innovadoras que satisfagan las necesidades humanas.(Compromiso, Innovación, Curiosidad)
  • Las personas ágiles adoptan activamente la diversidad y la inclusión para crear comunidades donde las personas se sientan seguras y a las que realmente pertenezcan.(Diversidad, Seguridad, Pertenencia)
  • Las personas ágiles se conectan profundamente con las personas, las empresas y la sociedad para crear una cultura donde se fomente, valore y libere la capacidad humana.(Cultura, Conexión, Humanidad, Enfoque en una sociedad más amplia)
  • Las personas ágiles persiguen continuamente el significado y el propósito en la vida para crear un impacto positivo y significativo en el mundo del trabajo.(Propósito, Significado)
  • Las personas ágiles buscan activamente oportunidades para experimentar y aprender a adaptarse rápidamente y prosperar en un entorno cambiante.(Adaptabilidad, Experimentación)
  • Las personas ágiles promueven la transparencia entre las organizaciones y los equipos para permitir la confianza, la responsabilidad y la autoorganización.(Transparencia, Compromiso, Responsabilidad, Autoorganización)
  • Las personas ágiles aprovechan el poder de los límites para facilitar la colaboración proactiva a través de las barreras organizacionales.(Multifuncional, Colaboración, Comunicación, Aprendizaje)
Bala Asirvatham, Cheryl Tansey, Claudio Lingua, Ed Cadura, Gustavo Couto, Helgi Gudmundsson, Inanc Civaz, James Stone, Kjell Tore Guttormsen, Michele Stone, Mikael Leinsköld, Ola Berg, Pablo Delgado, Pan Wei Ng, Pia-Maria Thorén, Steve Conard, Tamara Molinas, Wouter Bak, Åsa Holmberg

lunes, 2 de septiembre de 2019

¿Por qué los Gemba Walks son tan importantes?

El término Gemba proviene del japonés y significa "el lugar real"; el lugar más importante para un equipo, el lugar donde se desarrolla el trabajo real. El Gemba Walk, o visita al lugar real, es una parte esencial de Lean cuyo propósito es fomentar que los directivos y líderes observen y adquieran conocimiento sobre el proceso de trabajo real, interactuando con los equipos y construyendo confianza mutua para explorar oportunidades de mejora continua.
Hay 3 elementos importantes en un Gemba Walk
  • Ve y observa: La idea principal es que los directivos y líderes de todos los niveles realicen Gembas Walks regulares para observar el proceso de trabajo real y averiguar cuales son las condiciones más adecuadas para realizar el trabajo.
  • Pregunta ¿por qué?: Muchas cosas suelen hacerse por rutina y sin preguntarse si están bien o mal, el objetivo principal de las preguntas es entender al detalle el flujo de valor y localizar las causas raíz de las partes problemáticas y así poder eliminar desperdicio (muda). Para ello es necesario hablar con los equipos, los que viven el proceso en primera persona, y preguntarles con ánimo de entendimiento cosas como "¿qué estás haciendo?" y "¿por qué lo haces así?".
  • Muestra respeto: La mejor manera de mostrar respeto es incluir a los equipos en las acciones de solución a problemas y la generación de ideas innovadoras para que puedan tomar parte en la mejora continua de su propio trabajo. Con ello se maximiza el compromiso y la aceptación y sostenibilidad de la solución.
Uno de los beneficios más importantes es la conexión que los Gemba Walks permiten construir entre un líder y los miembros de los equiposEn las compañías tradicionales, que se basan en un modelo de la obediencia, existe una desconexión entre las capas de mandos intermedios y la realidad de los equipos; hablas con unos y otros y observas que los directivos hablan de números y dan un mensaje de que todo está controlado, mientras que los equipos hablan de realidades y que estas suelen ser muy distintas.

Un experimento muy elocuente en una gran compañía española fue preguntar a estos dos niveles qué es lo que creían que motiva a los equiposLos miembros de equipos marcaron opciones como el desarrollo profesional, la maestría, la autonomía y la formación como motivadores principales, básicamente motivadores intrínsecos. Las capas directivas estaban convencidas de que el motivador principal para esos mismos miembros de equipos era principalmente el dinero, el motivador extrínseco por excelencia.

Se desprende de este experimento que el motivador principal para los directivos suele ser el dinero, un motivador extrínseco. Para experimentar motivadores intrínsecos, como ocurre con los equipos, es necesario participar de la realidad, ver la realidad a través de números anula la motivación intrínseca.

Es por ello que los Gemba Walks son tan importantes, impregnan a la capa directiva de realidad de la compañía, que por ende es la realidad de las personas que están en la primera fila de la acciones, permitiéndoles así tomar mejores decisiones y acciones desde un punto de vista sistémico y de mejora continua.

domingo, 25 de agosto de 2019

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

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.

Personas sobre procesos - cortesía de Pixabay
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.

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 no será una moda, será un necesidad para poder sobrevivir.

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.