Guía de historias de usuario

Portada de la guía de historias de usuarioYa se encuentra disponible la guía Historias de usuario, revisada y actualizada en la nueva versión 2.o

Es un trabajo colaborativo realizado por Alexander Menzinsky, Gertrudis López y Juan Palacio, producido por  Scrum Manager para compartir de forma abierta.

Lo podéis  descargar desde el siguiente enlace: Descarga Historias de Usuario 2.0

Y también verlo con los autores en el curso de ampliación de Scrum Manager: Historias de usuario, disponible con acceso libre en OKs.

¿Cómo experimentar un proyecto con cascada y luego con Scrum?

Una de las formas más potentes para experimentar Scrum es hacerlo mediante la comparación. Primero experimentar la construcción de un producto por fases en cascada, para luego vivir la construcción del mismo producto mediante sprints que incorporen feedback y aprendizaje de forma natural.

Imagen del ejercicio
El producto: tarjetas de invitación de cumpleaños

Alexandre Magno ha ideado la simulación que expongo en este post, me parece excepcional, la hemos liderado juntos y la voy a incluir en mis cursos de Scrum. Para poner contexto explicamos a los asistentes que nuestro hijo quiere invitar a 12 amiguetes a su cumpleaños y necesita 12 tarjetas de invitación. Resulta que le hace mucha ilusión que las invitaciones tengan un payaso sonriente pintado en la portada. Continue reading “¿Cómo experimentar un proyecto con cascada y luego con Scrum?”

Scrum Level en un vistazo

Scrum Level en un vistazoAbordar modelos ágiles de trabajo y organización en un equipo no es una tarea sencilla, y sin duda se vuelve mucho más compleja cuando se pretende escalar a toda la empresa.

Con el enfoque de agilidad flexible y global de Scrum Manager, compartimos el conocimiento que desarrollamos desde la experiencia profesional para afrontar el reto de agilizar una empresa.

Lo podéis encontrar en Scrum Level, que incorpora también un protocolo con derechos de uso liberados para facilitar la “radiografía” de la empresa, con sus retos y características.

Autoorganización de equipos y cultura de empresa

“Los trabajadores del conocimiento tienen que autogestionarse. Deben tener autonomía” (Druker, 1999)

La autonomía en la organización de un equipo puede producirse en distinto grado, dependiendo del ámbito de responsabilidades que gestionan sus miembros; desde el mínimo, en el que cada persona sólo asume la responsabilidad de las tareas que tiene encomendadas, hasta el máximo en el que todas las funciones de desarrollo, gestión de tareas, diseño del marco de trabajo y participación en la estrategia global son asumidas por los miembros del equipo.

Se pueden establecer 4 niveles de autogestión para los equipos, desde el mínimo, propio de los equipos dirigidos, y que no se pueden considerar autogestionados, hasta el máximo, que podemos denominar equipos autogobernados:

1.- Equipos dirigidos.

En ellos los miembros del equipo sólo tienen autoridad en la ejecución de las tareas. Son los gestores quienes administran el proyecto y las tareas, monitorizan el avance, diseñan el marco de trabajo y participan en las decisiones estratégicas para la organización.

2.- Equipos autogestionados.

Los miembros del equipo tienen autoridad para ejecutar las tareas y también para gestionarlas en el marco del proyecto. Es el caso de los equipos que emplean marcos técnicos de scrum o kanban para gestionar el desarrollo.

3.- Equipos autodiseñados.

Los miembros del equipo, además de ser responsables de la ejecución de las tareas y de la gestión de las mismas en el ámbito del proyecto, también diseñan el modelo organizativo interno del equipo y el marco de trabajo que emplean.

4.- Equipos autogobernados.

Además de las responsabilidades de los equipos autodiseñados, en los equipos autogobernados los miembros tienen también capacidad de decisión sobre las decisiones estratégicas de la organización en las que el equipo participa o se encuentra implicado .

Al analizar la autoorganización se debe considerar que el nivel 2 o de equipos autogestionados puede resultar suficiente para facilitar la agilidad en el ámbito operativo, pero para facilitarla también en el ámbito organizacional se requiere un nivel 3 (equipos autodiseñados) para organizaciones con un patrón cultural verde, y 4 en organizaciones con un patrón cultural teal (Laloux 2016)

Texto extraído de Scrum Level 2.0: la agilidad para la empresa, por Scrum Mananger, Autoorganización, Pág. 37

Druker, P.F. (1999). Knowledge-Worker Productivity: The Biggest Challenge. California  Management Review, 78-94.
Laloux, F. (2016). Reinventar las organizaciones. Barcelona: arpa editores.

 

Scrum Level 2.0: La agilidad para la empresa, por Scrum Manager

Portada Scrum Level 2.0Ya está disponible la versión 2.0 de Scrum Level: una síntesis de conocimiento estructurado para guiar la mejora de la gestión ágil en las empresas.

Es un trabajo colaborativo dirigido por Scrum Manager  desde la experiencia profesional de formación y asesoría,  publicado de forma abierta para compartir el conocimiento con todos los profesionales a los que pueda resultar útil.

scrumlevel.com

 

¿Cuál es el talón de Aquiles de SAFe?

Tuve una conversación con Marcos que no me dejó impasible. Ya sabéis que creo en SAFe y me gusta, creo que es un marco Agile y Lean hasta la médula, pero Marcos fue capaz de arrojar una nueva luz a mis principios.

Si lo miramos con detenimiento Scrum trata de simplificar la complejidad, una empresa es Agile cuando ha simplificado sus estructuras organizativas y funciona de forma plana y fractal.

En cambio SAFe es un marco complejo que trae complejidad, por tanto no pone el foco en la simplicidad como lo hace Scrum. Recordemos el décimo principio del Manifiesto Ágil:

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

SAFe sustituye la complejidad organizacional y jerárquica de una compañía por una complejidad Agile y Lean, pero no simplifica, y si no simplifica ¿no va a atar a la empresa a SAFe y a su complejidad? Esto hace cuestionarnos si la empresa que implante este marco pueda tener la oportunidad de ser Agile puro, y si esta va a tener la oportunidad en el futuro de ir más allá de SAFe. Con SAFe lo que puede ocurrir es que se mantenga atascada en un nivel de complejidad similar al de antes de la transformación…

En mi realidad las empresas que pueden ser Agile ya lo son, ahora estamos lidiando con empresas que nunca serán Agile de verdad, grandes compañías y consultoras con cientos de empleados que difícilmente pueden apostar por la persona y empoderarla en su talento. Vender Agile puro a estas empresas es difícil, SAFe tiene un big picture suficientemente complejo o “feo” para que estas empresas se interesen y haya posibilidades de implantarlo. SAFe es un punto de partida que puede funcionar para acercar la compañía a Agile, ¿pero permitirá a la empresa ser Agile de verdad?

Probablemente no, pienso que SAFe alargará la letanía de las empresas que no son conscientes de la nueva realidad del mundo VUCA, un mundo inmerso en la turbulencia del cambio. Las que sobrevivan serán Agile de verdad, e incluso Teal, pero las que no están condenadas a desaparecer sin compasión.

 

¿Cómo guiar y mantener a una tribu en un entorno correcto, motivante y productivo?

Cuando trabajamos con Scrum de forma escalada a nivel de equipo de equipos, se hace imprescindible un rol cuyo foco sea el equipo de equipos como un solo ente, de forma holística. El foco en los detalles está en aquellos que tratan directamente con los equipos de desarrollo, los Propietarios del Producto y los Scrum Masters entre otros.

Para cubrir este rol el modelo Spotify introduce al Tribe Lead, un líder al servicio que primero acompaña a la tribu a través de las etapas de la adopción de Agilidad a nivel de escala, y luego la conduce a lo largo de la estrategia y la mejora continua. Establece la estrategia en base a la visión y los objetivos a largo plazo de la compañía, y se centra en sincronizar la cultura con la estrategia para involucrar a la tribu en los valores ágiles, causas nobles, resultados (outcomes) y adopción de nuevos hábitos y así alinear los comportamientos con la Agilidad.

Continue reading “¿Cómo guiar y mantener a una tribu en un entorno correcto, motivante y productivo?”

¿Cómo liderar el crecimiento de equipos impulsados por las motivaciones intrínsecas?

Participantes de las reuniones POCLACAquellos con roles de liderazgo ágil deben de hacer todo lo posible para que los equipos aprendan y crezcan de forma continua, en un ambiente adecuado con el objetivo de hacer equipos más productivos y motivados. En Agilidad el liderazgo se hace en equipo y por aquellos roles que pueden facilitar las motivaciones intrínsecas de los miembros del equipo: propósito, maestría y autonomía.

En los diferentes marcos de Agilidad, desde Scrum a los marcos escalados, nos encontramos con un liderazgo distribuido en una coalición de tres roles:

  • En Scrum el Propietario del Producto lidera mediante el propósito, el Scrum Master entrena en la autonomía y el propio equipo desarrolla la maestría.
  • A nivel de programa en SAFe, el nivel de equipo de equipos, Product Management aporta el propósito, el Release Train Engineer (RTE) pone el foco en la autonomía del equipo de equipos y Sistemas/Ingeniería/Arquitectura guía en la maestría.
  • En el modelo Spotify el Propietario del Producto representa propósito, el Chapter Lead la maestría, aportando conocimiento, y el coach ágil impulsa la autonomía.

Continue reading “¿Cómo liderar el crecimiento de equipos impulsados por las motivaciones intrínsecas?”

Agilidad en la empresa: ¿en el producto, en la cultura o en todo?

En las empresas conviven dos dimensiones: una operativa, que realiza los productos o servicios de la compañía; y otra organizativa, que define y gestiona la cultura, estructura y modelo de gobernanza con el que se rige.

A menudo se aborda el escalado de agilidad de forma conjunta en ambas dimensiones. Se introducen modificaciones tanto en la gestión de los proyectos y los procesos de desarrollo, como en la cultura y el modelo de gobernanza.
Se actúa así, porque se considera que la agilidad implica cambios operativos y organizativos de forma simultánea, y por tanto no se valora por separado:

  1. Si el producto, servicio o proyecto de la empresa se puede construir de forma evolutiva, y si proporciona ventajas a los clientes o la comercialización.
  2. Si la propiedad de la empresa desea cambios en la estructura o en el modelo de gobernanza, y si es consciente de las implicaciones de esos cambios.

Cuando no se necesita o no se puede entregar de forma incremental, escalar la agilidad en la empresa no consiste en institucionalizar un marco de prácticas de desarrollo evolutivo, sino estructuras organizativas fractales y modelos de gobernanza dinámica.

Es el caso, por ejemplo, de AES (sector energético, 40.000 empleados), Heiligenfeld (Hospitales de salud mental, 600 empleados) o Zappos.com (venta de zapatos on line, 1.500 empleados)

Si el objetivo de la empresa se centra en el beneficio de los accionistas. Si basa el know-how de sus productos en ingeniería de procesos antes que en el conocimiento tácito de las personas, el escalado de la agilidad fracasará si implica introducir no sólo prácticas de agilidad técnica, sino también un nuevo paradigma cultural.

Diagrama cartesiano para reflejar en el eje vertical la agilidad en la dimensión organizativa, y en el eje horizontal la agilidad en la dimensión operativa, reflejando de esta forma 3 patrones de agilidad posibles: Agilidad organizativa, agilidad técnica y agilidad dual.

(*) Saber más acerca de cultura naranja, verde o teal.
Continue reading “Agilidad en la empresa: ¿en el producto, en la cultura o en todo?”