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?”

Agilidad: ¿Empresa naranja o verde?

Puede ser un error emplear el mismo marco de escalado de agilidad para todas las empresas. En organizaciones naranjas puede bastar un marco técnico para iterar haciendo ingeniería concurrente. En organizaciones verdes, o que quieren evolucionar al verde o teal se necesitará también evolucionar la estructura y la cultura.  Pero ¿de qué va esto de “naranja”, “verde” y “teal” ?

Este artículo esboza la base teórica: el modelo de paradigmas culturales de Frederic Laloux(1).

Según Laloux, la evolución de los valores y principios culturales de la humanidad viene marcando el tipo de organizaciones que creamos.
Aunque el estudio de los distintos paradigmas culturales contempla modelos de organización prehistóricos, a los que denomina infrarrojo y magenta, los que nos interesa conocer desde la perspectiva de gestión de las organizaciones actuales son los cinco últimos. Los denominados: rojo, ámbar, naranja, verde y esmeralda o teal.

Diagrama que muestra la duración de los paradigmas culturales: El infrarojo desde la prehistoria hasta unos miles de años antes de Cristro. El magenta, desde las primeras civilizaciones hasta los albores de la historia, y la aparición posterior del rojo, ámbar, naranja. verde y teal, y cómo en la actualidad se da la convivencia de estos 4 últimos. Continue reading “Agilidad: ¿Empresa naranja o verde?”

Scrum: corriendo por la sangre de los equipos de alto desempeño – Scrum Bike

Mayo, mes en el cual se da una de las carreras de bicicletas de ruta más famosas, El Giro de Italia. Se me ocurrió usar la analogía del funcionamiento de un equipo de alto desempeño, que puede ser sobre cualquier competencia, para explicar el marco Ágil Scrum.

Y ustedes dirán, ¿Y qué tiene que ver Scrum con las competencias por equipo en bicicleta? Bueno al principio no mucho, pero poco a poco, fui descubriendo, cómo ir relacionando una cosa con otra.
¡Vamos a la ruta! Continue reading “Scrum: corriendo por la sangre de los equipos de alto desempeño – Scrum Bike”

PPT para Kanban Pizza Game

Kanban Pizza GameEl juego interactivo Kanban Pizza Game es una idea original de agile42.com que muestra el funcionamiento de un sistema kanban.

Mientras que otros ejercicios se centran en enseñar cómo es el flujo de un sistema kanban preexistente, este juego muestra la forma y los beneficios de gestionar visualmente con kanban un proceso real no gestionado previamente.

Además es divertido 🙂

Compartimos estas diapositivas para conducir la dinámica del juego, del fondo de material de Jordi Ariño, colaborador y profesor de Scrum Manager en PUE.

Créditos:

Con licencia cc by sa