Guillem Hernandez Sola

El refinamiento del Product Backlog es la actividad imprescindible en cualquier equipo Scrum de añadir detalles, descubrir, estimar y ordenar a los elementos del Product Backlog. 

La agilidad de negocio es la capacidad de deleitar continuamente a los clientes con entregas de valor e inspirar a los empleados en medio de los desafíos emergentes. 

Vamos a proporcionar una descripción general rápida de cada animal, veremos por qué son tan peligrosos y ofreceremos algunos consejos sobre cómo domesticarlos para ver qué animal de producto eres o son los que te rod

Ponerse metas siempre es importante. Tener rumbo siempre es importante. ¿Pero qué pasa si una organización no tiene claras sus metas?

Hoy me vengo arriba un poco. Vengo a comentar que competencias creo que tendría que tener un líder agile.

Me cuesta mucho imaginarme una capacitación sin que algun participante me pregunte por la daily. 

Me he encontrado muchísimas organizaciones que lo primero que quieren hacer la agilidad de lo grande. En lo primero que piensan es en cambiar enteras. Si somos 5000, vamos a hacer un plan para cambiar los 5000. Y Roma no se hizo en un día. Se fue construyendo con el tiempo. Por eso se extrañan cuando lo primero que digo es que se tiene que empezar pequeño. Pequeño para mí es empezar con un grupo de 10 a 30 personas máximo relacionadas directamente en solucionar un problema concreto. Cuando digo un problema concreto me estoy refiriendo a navegar la incertidumbre que puede producir la gestión y desarrollo de un producto. Y en eso encaja la agilidad, la creación de valor de manera iterativa e incremental. Luego siempre me comentan que tenemos que ir a lo grande. De acuerdo, dejadme mostrar como entiendo la agilidad a lo grande. Imaginad que tenemos, una organización con 3 lineas de producto. Ahí voy a vislumbrar como veo la agilidad a lo grande. Cómo veis en la foto anterior, hay un punto central de donde emana el liderazgo y servicios compartidos para toda la organización. Acto seguido, una separación muy clara de 3 productos donde como veis usan Nexus en algunas y Scrum puro en otras. Además esta idea la acompaño con EBM y con métricas de flujo kanban a nivel el value stream de cada uno de los productos. No tiene sentido tener métricas transversales aquí, ya que cada producto es un ecosistema que vive por si solo. Los servicios compartidos estan en el centro, en el Scrum Studio y ahi si tienen sentido partes transversales. A partir de aquí empiezar a aterrizar la primera idea de montarme un pequeño esquema mental que tiene 3 capas. Las 3 capas de agilidad a lo grande basadas en Scrum Studio son las siguientes: Liderazgo y estrategia Coordinación de extremo a extremo (end-to-end coordination) Operaciones sobre el value stream del producto Liderazgo y estrategia a lo grande El liderazgo ágil requiere desarrollar una estrategia y consultarla regularmente. Esto encaja con la manera iterativa e incremental de funcionar de la agilidad. En una organización ágil, una estrategia bien pensada y revisada con frecuencia es el verdadero norte de la empresa. Y esto se puede llevar a lo grande. Además la transparencia es clave dónde cada colaborador individual debe comprender la estrategia básica de la empresa y cómo su trabajo individual se cruza con ella. Dado que el liderazgo ágil prospera experimentando e iterando la mejora continua, invariablemente hay un elemento de incertidumbre. Si bien no se puede eliminar, se puede manejar con ciertos marcos de trabajo basados en las metodologías ágiles. Coordinación de extremo a extremo De extremo a extremo se refiere a la entrega de sistemas o servicios complejos en forma funcional después de desarrollarlos de principio a fin. End-to-end es más común en el sector de TI, en el mundo del software, pero cada vez es más común en otros dominios. El procesamiento de extremo a extremo ayuda a optimizar el rendimiento, la colaboración y la eficiencia de una organización. A ese nivel es vital la colaboración y la transferencia de conocimiento para hacer crecer la organización muchos niveles. Operaciones sobre el value stream del producto El mapeo de flujo de valor o value stream es un método de gestión ajustada para analizar el estado actual y diseñar un estado futuro para una serie de eventos que se toman un producto o servicio del inicio del proceso específico hasta llegar al cliente. Un mapa de flujo de valor es una herramienta visual que muestra todos los pasos críticos en un proceso específico y cuantifica fácilmente el tiempo y el volumen necesarios en cada etapa. Los mapas de flujo de valor muestran el flujo de materiales e información a medida que avanzan a través del proceso. Este diagramo de cadena de valor muestra una descripción general de todas las actividades dentro de una organización para realizar un producto. Esa parte sea aliena totalmente con la coordinación extremo a extremo y con la estrategia a lo grande. Mi conclusión Llegados a este punto, me gustaría romper una lanza para cambiar el término escala por a lo grande. Todo el mundo habla de agilidad escalada, pero lo que quieren es llevar su pequeño mundo, ya sea un equipo o un grupo hacia una gestión más alienada con la estrategia de la organización. No hace falta ir a buscar la mejor consultora de negocio del mundo para decirte que trabajar en 3 capas. Recuerdo que el liderazgo con estrategia definida, coordinación extremo a extremo y operativa para dar valor seria un camino para empezar a explorar.

Hoy he venido profundo y filosófico. Siempre en mis formaciones comento la diferencia entre ordenar y priorizar.

El Manifiesto Ágil aún es relevante para proyectos de precio fijo No me canso de recordar un mis capacitaciones y consultorias que el Manifiesto Ágil aun sigue siendo relevante y más vigente que nunca. De hecho siempre recuerdo que nació en 2001, porqué me he encontrado una organización que me afirmó activamente que llevaban haciendo durante los últimos 25 años. No me salen los números en su implementación de la agilidad. El Manifiesto Ágil también comprende una docena de principios que subyacen a los cuatro valores. Sostengo que cada uno de los doce principios complementa los proyectos de precio, alcance y fecha fija. Y vale la pena destacar un par. “Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de software valioso” es el primer principio del Manifiesto, y por una buena razón. En 2022 podriamos cambiar la palabra «software» por la palabra «solución» por la evolución natural el mercado de la agilidad. Mientras trabajas en un proyecto de fecha fija o de alcance fijo, buscas oportunidades para ofrecer suficiente valor para que el cliente no necesite todo lo que anticipó inicialmente. Uno de mis primeros trabajos fuera de la universidad fue trabajar en una empresa grande. Después de estar allí unos meses, recuerdo haber almorzado con mi jefe, quien me dijo que mi trabajo era encontrar formas de ampliar el alcance de los proyectos en los que estaba asignado. Esa iba a ser siempre mi primera preocupación, dijo, incluso por encima de completar con éxito un proyecto. No hace falta decir que dejé esa firma unos meses más tarde tan pronto como pude encontrar una empresa más interesada en colaborar con sus clientes. En lugar de buscar formas de expandir el alcance de un proyecto, tienes que estar atento a terminar antes creando un producto con suficiente funcionalidad para que el resto no sea necesario. Bienvenido Cambio de requisitos Creo que uno de los principios más importantes del Manifiesto es: “Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente”. El cambio sucede. Lo sabemos. Es posible que necesitemos convencer a nuestros jefes, clientes y clientes de su inevitabilidad, pero eso se puede hacer. Los otros diez principios del Manifiesto, incluido el énfasis en la simplicidad, las personas motivadas, la comunicación cara a cara, el ritmo sostenible, la autoorganización, la reflexión, el trabajo conjunto y la entrega frecuente, también respaldan proyectos con fechas y alcances fijos. ¿Son ágiles los proyectos de precio fijo, alcance y fecha? Entonces, ¿este tipo de proyectos son ágiles? Sí, pueden ser. El objetivo de un equipo debe ser ser lo más ágil posible dado el contexto en el que trabaja el equipo. Todos los proyectos tienen restricciones. Un proyecto para el cual el equipo tiene siete personas y el equipo no se puede expandir necesita ser ágil dentro de ese contexto. Un equipo al que se le dice que debe entregar en una fecha determinada debe ser ágil dentro de ese contexto. Piensa en las restricciones como la definición del espacio de solución dentro del cual opera un equipo. Por supuesto, hay un punto en el que si impone demasiadas restricciones a un equipo, ni siquiera Agile ayudará a los miembros del equipo a encontrar una solución. Pero un conjunto de restricciones más manejable aún deja espacio para que un equipo sea ágil. No serán tan ágiles como un equipo sin esas limitaciones, pero aún pueden ser ágiles dentro de ese contexto.

Es tentador imaginar un mundo en el que todos los proyectos a precio fijo se inicien sin plazos y continúen hasta que las partes interesadas decidan que se ha entregado suficiente valor.