Volver
TAYARI LAB
Golden Gate Bridge

La relación entre el modelo de fluidez ágil y las topologías de equipos


Tenemos dos modelos muy populares en el contexto de la agilidad de desarrollo de producto digital: el modelo de fluidez ágil (AFM) de Diana Larsen y James Shore, y las topologías de equipos de Manuel País y Matthew Skelton. Hace poco hablábamos en la comunidad de AFM de la relación entre ambos, y salieron algunas ideas interesantes.

No encaja una comparativa como tal entre ambos, pues son modelos de naturaleza diferente, ven los equipos desde perspectivas diferentes. Veremos qué relación puede existir entre ellos.

Hagamos un repaso muy rápido de ambos:

El modelo de fluidez ágil.


El modelo de fluidez ágil representa cómo los equipos siguen una progresión típica en su entendimiento de los métodos ágiles y los beneficios que recibe la organización. Personalmente me convenció (aparte de la solidez intelectual demostrada por sus autores) por que se centra en los beneficios esperados de la agilidad. No es un modelo de prácticas, un listado/checklist de prácticas que tienes que ir avanzado para seguir al siguiente nivel. Cuando prometemos que la agilidad va a solucionar algún problema (nota: ¡no lo hagas!) debemos ver BENEFICIOS de su implantación.


El modelo presenta 4 zonas por las que evolucionan los equipos:


Zonas del modelo de fluidez ágil




  • Focalizando, requiere un equipo que aprenda a trabajar junto para focalizarse en crear valor de negocio en vez de simplemente finalizar tareas técnicas. Se obtiene visión sobre el equipo del trabajo, transparencia, y tendrá más oportunidades para influencia el trabajo en direcciones positivas. Esta zona refleja lo básico de Agile.

  • Entregando, requiere que un equipo invierta en aprender una serie de habilidades en el desarrollo de software. Esta zona refleja la sostenibilidad Agile. Las habilidades no se obtienen fácilmente, pero con tiempo y el adecuado apoyo organizacional, el equipo obtiene la habilidad de crear y lanzar software con una baja tasa de errores tan pronto como el mercado lo acepte, lo que proporciona a la organización nuevas oportunidades para lograr retorno de la inversión en su desarrollo software.

  • Optimizando, representa la promesa de Agile: un equipo que baila y se mueve al son de las condiciones cambiantes del mercado, y toma responsabilidad compartida para construir el mejor producto que la inversión pueda comprar. Conseguir la fluidez en esta zona significa que los expertos del negocio deben unirse a los equipos como participantes a tiempo completo, y mientras que este cambio de la estructura organizativa puede ser un reto, es beneficioso mejorando la habilidad de tus equipos para servir al negocio.

  • Fortaleciendo, representa el futuro de Agile. (no tratada por los autores en su diagnóstico)



Estas zonas no son secuenciales, y pueden ser independientes en su logro, si bien, la observación de los autores (que comparto), es que es el camino más habitual.

Topologías de equipos


Las topologías de equipos representan la situación de un equipo respecto a su cadena de valor:

Key Concepts — Team Topologies


 Las cuatro topologías de equipos:

  • Equipos focalizados en una cadena de valor, capaces de entregar a cliente/usuario lo más independientemente posible.

  • Equipos de soporte, ayudan a otros equipos a cubrir una necesidad (tecnológica o de dominio) para aumentar su autonomía.

  • Equipos de subsistemas complejos, responsables de construir y mantener parte del sistema que requiere habilidades o conocimiento especiales.

  • Equipos de plataforma.


Y no solo habla de las topologías de los equipos, si no de sus interacciones: X-as-a-service, colaboración y facilitación.

Ninguno de los dos modelos definen una situación para los equipos ideal, si no que dan herramientas para identificar su situación, y trabajar en su desarrollo. Las topologías desde el diseño organizativo de los equipos (composición y relaciones) y AFM desde el nivel de capacidad del equipo para una entrega continua, adaptable y de calidad (vamos a decir, "ágil").

Entonces, ¿Hay una relación entre zonas del modelo de fluidez ágil y la tipología del equipo?

 

Si tenemos diferentes tipologías de equipos, y diferentes zonas de fluidez ágil en las que se puede encontrar cada uno de ellos, ¿existe zonas más apropiadas según la tipología? ¿requieren diferentes tipologías de diferentes capacidades o habilidades a conseguir?

 

Mi primera idea es que el modelo de fluidez y las tipologías son ortogonales. Por un lado hablamos del objetivo o lugar del equipo dentro de la cadena de valor, y por otro de las habilidades conseguidas de este equipo respecto a su capacidad y nivel de entrega.

 

Ambas hablan obviamente de una aproximación organizacional por equipos. Sin que la organización decida trabajar por equipos es difícil empezar a obtener los beneficios esperados de la agilidad. Hay una necesidad del salto indicado para la primera zona, FOCALIZANDO. Obviamente, antes de esta zona ni siquiera hay conciencia de equipos en una organización, por lo que no tendremos probablemente ni un planteamiento de topologías de los mismos.
Parece trivial decirlo, pero aún hay muchas organizaciones que no han dado el salto, y o no lo creen o no lo es, necesario para su modelo de negocio.

 

Por tanto, sea cual sea la topología de equipo, necesita de la zona FOCALIZANDO para poder entregar con transparencia, y conseguir un mínimo de adaptabilidad y trabajo priorizado por valor en unidades significativas para el negocio. Significa al menos hacer la inversión para crear equipos reales, lograr mecanismos de trabajo transparentes, y un proceso de mejora continua. Como Diana y James lo declaran es el beneficio básico de Agile.

 

¿Qué sucede con el resto de zonas?

 

- Los equipos de entrega en la cadena de valor, se beneficiarán de la zona ENTREGANDO especialmente si sus productos van a ser sostenidos en el tiempo, donde necesitan mantener bajo control la deuda técnica y altos estándares de calidad interna. Se beneficiarán de la zona OPTIMIZANDO si necesitan actuar rápido en el mercado, experimentar con opciones, y liderar su mercado objetivo.
Estos equipos son los que más se beneficiarán de la zona OPTIMIZANDO pues es dónde se trabaja la respuesta adecuada al mercado y su adaptabilidad al negocio.
- Los equipos de plataforma los situo en una zona ENTREGANDO como zona necesaria. Si una organización está creando plataformas para dar servicio al resto de equipos, la calidad del producto, su capacidad de entrega continua, debe estar siempre por encima de los equipos a los que da servicio o se crearía un cuello de botella artificial. La zona OPTIMIZANDO probablemente es menos necesaria, pues su gestión de requerimientos no está en contacto directo con el mercado.
- Los equipos de soporte necesitan trabajar al menos al mismo nivel técnico en la zona ENTREGANDO que a aquellos equipos a los que sirven. Imagino que muchas veces tendrán la responsabilidad de elevar el nivel en esta zona misma a los equipos a los que ayudan.

 

- Los equipos de sistemas complejos deben maximizar los resultados deben decidir cuál es la inversión necesaria para dar el mejor servicio al resto de equipos.
 
Si las representamos sería algo así:

Relación tipologías equipos y modelo de fluidez

Este podría ser un mapa objetivo, pero podríamos tener un mapa de los equipos de la organización, incluyendo la zona actual y la zona deseada. Cada zona puede tener diferente grado de consecución, y podremos observar patrones de necesidades por tipo de equipo.

¿Y si las relacionamos a través de un mapa?

Creo que lo interesante de estos modelos no es analizarlos en un marco teórico, si no en su contexto y evolución en las organizaciones. Ambos hablan de la evolución de los equipos, uno desde la estructura organizacional y otro desde las habilidades y capacidades de los equipos. Ni una cosa ni la otra son estáticas en una organización de desarrollo de software, y se tienen que ir adaptando a las necesidades como pueden ser de crecimiento o escalabilidad o las del mercado cambiante.
 
Y para hablar de modelos en evolución, podría ser interesante traer los mapas de Wardley. Muy básicamente, en ellos situamos nuestros elementos en dos ejes: su posición en la cadena de valor, y en la evolución del producto.
 
Topologias y modelo fluidez en Wardley Map
 

ANEXO: Las tipologías que nos encontramos.

Lamentablemente, estas son algunas de las topologías  disfuncionales de equipos que nos encontramos en muchas organizaciones de desarrollo de producto:
 
- Equipo de llego hasta dónde puedo y paso la pelota al siguiente: Los equipos front-end y back-end, los equipos con múltiples dependencias para cualquier funcionalidad...
- Equipo de comunicación: Como, por ejemplo, el equipo de front y el de back se llevan mal y no se entienden, establecemos un canal de comunicación que define y despliega servicios entre ambos, y por tanto una plataforma más, claro.
- Equipo de despliegue: Un equipo para hacer los pases a entornos de Producción. Dado un word y un código fuente, tenemos un despliegue exitoso en PRO.
- Equipo de recursos: Cuándo el equipo ni sabe qué personas tiene esa semana, ni cuánto pueden dedicar a trabajar juntos.

Seguir investigando

La idea de las topologías de equipos según la situación en el mapa de Wardley y su identificación de la zona de fluidez necesaria es un trabajo en progreso. Creo que puede dar mucha información para facilitar las conversaciones alrededor de la evolución de una organización, pero quizás está un poco sobrecargado. ¡Si tienes alguna idea, no dejes de escribirla en los comentarios!

Volver
Volver
TAYARI LAB

El rol del Scrum Master es uno de los peor entendidos cuando hablamos de Scrum, ¿y cómo se relaciona con el de manager?. Es un rol específico de un marco de trabajo ágil: Scrum, que se ha convertido en el más utilizado en las organizaciones. Sin embargo parece que ha conquistado cualquier empresa que intenta implementar/transformar caminos más ágiles. Si decides tener Scrum Masters en tus equipos, debes entender bien la figura. Ya tradujimos en su día las 42 tareas que debe hacer un Scrum Master, y no parece poco ¡aunque sea sólo para un equipo!

El Scrum Master es el nuevo manager

«No necesitamos Scrum Masters que sean managers, pero necesitamos managers que se conviertan en Scrum Masters». ¿Por qué?

1. El manager trabaja para su equipo

La idea fundamental aquí es «Producto = Equipo» (de Software for your head). El producto será tan bueno (o malo) como el equipo que lo ha construido. Así que alguien debe trabajar en que los equipos mejoren, y los resultados que emerjan del mismo sean como consecuencia lo más adecuado.

Cada miembro del equipo debe asumir esa responsabilidad, sin duda, pero hoy por hoy, poca gente tiene capacidad de leer y actuar sobre la situación de su propio equipo. Yo estudié (hace muchos ya) 5 años de Ingeniería de Software, y jamás me hablaron de «personas». Error fundamental, que espero que actualmente haya cambiado.

2. Trabaja para las personas del equipo, que mejoren y evolucionen

La emergencia es fundamental -el resultado de la interacción entre las partes, como decíamos en el punto anterior-, pero también trabajar en las personas, los nodos. Se debe aprender a colaborar y trabajar en equipo. También cada uno en su trabajo técnico, pero aquí el enfoque es en trabajar las relaciones desde las personas.

Ayudar a comunicarse mejor, a trabajar con mejores herramientas colaborativas (tanto en presencia física como en online), a crecer como individuo único en un grupo, son valores que el scrum master debe fomentar.

3. Alinea las personas en base a una visión

La organización debe tener una misión/visión para el trabajo del equipo. Como Scrum Master debes velar por que esté clara y el equipo tenga las mejores herramientas y procesos de feedback para alinearse con la misma.

No tiene por qué intervenir en la creación de esa visión, pero sí trabajar y facilitar para que los grupos (y en especial el equipo) en la organización la mantengan clara y trabajen sus discrepancias. Aquí es fundamental que trabaje en los elementos para implantar un desarrollo iterativo e incremental como procesos de feedback continuos.

4. Reafirma la mejora continua

Todo lo anterior se debe reforzar desde una cultura de mejora continua. Apoyar los cambios, sugerirlos, retar al equipo para que descubra su proceso de mejora.

5. Tiene una visión sistémica, más allá del día a día o del sprint

Entiende qué rol juega el equipo en la organización, y cuáles son las fuerzas e impedimentos que le afectan. Trabaja con el resto de scrum masters para mejorar el sistema global, desde la perspectiva de la gestión de la demanda a las interacciones de los equipo, yendo más lejos que la simple solución de impedimentos puntuales.

6. Fomenta el aprendizaje y nuevas perspectivas

Siempre está escuchando las tendencias que podrían ayudar al equipo, trae nuevas ideas al equipo cuando las necesita. Facilita los procesos de aprendizaje.

7. Fomenta la auto-organización (mientras que trabaja en el sistema)

No quiere que el equipo dependa de su rol ni de él. De hecho, probablemente, ni se siente parte del equipo (! -esto dará para otro post-). El equipo trabaja con un objetivo común, él con otro diferente.

El manager: La realidad en las organizaciones

Estas cuestiones están lejos de la realidad de muchas organizaciones, y quizás hasta de la definición teórica del rol del scrum master. Un scrum master no tiene por que ser manager (tener autoridad formal sobre ellos) de un equipo, pero me gustaría que muchos más manager, especialmente mandos intermedios, tomasen roles más parecidos a los scrum masters. De esta manera podríamos tener organizaciones con personas trabajando en el sistema.

La jerarquía tradicional es confusa por que casi toda la delegación se hace alrededor de decisiones de demanda o producto, y esto complica innecesariamente la cadena de valor. Esas decisiones deben moverse a una perfecta colaboración entre los «extremos»: la alta dirección y los equipos en contacto con los clientes o mercado.

 

Volver
Volver
TAYARI LAB

¿Problemas en la transformación ágil? No debemos gestionar las dependencias, debemos eliminarlas. Nos matan la agilidad.

Rescatamos la presentación realizada en la CAS2016 por que sigue siendo de interés. Las dependencias en el desarrollo de producto digital en las organizaciones son la principal dificultad para el posible desarrollo ágil de software. No es muy útil organizarse en equipos si cada movimiento que realiza uno, lanza una miríada de dependencias alrededor de ellos, que los entorpecen, ralentizan y desesperan.

La idea fundamental es que el software refleja la estructura organizacional que lo ha creado (Ley de Conway). Si vas a cambiar la estructura organizacional, para ser más ágil, recuerda que ¡necesitarás invertir en adaptar tu producto también!

Las transparencias:

Además, puedes escuchar el audio de la charla: Audio "Las dependencias matarán tu transformación"

Volver
Volver
TAYARI LAB
15.05.2019

Open Space – Guía de facilitación

por: Joserra Díaz

"La opresión existe siempre que hay un monólogo donde debería haber diálogo."
—Paulo Freire

Los eventos tipo Open Space se están volviendo populares para gestionar conferencias. En vez de asignar charlas anteriormente al evento, y llegar con un programa predeterminado, los propios asistentes presentan, seleccionan y determinan las charlas al empezar el evento.

Pero el Open Space es un formato mucho más poderoso que para realizar "des-conferencias". Tuve la suerte de realizar un curso sobre facilitación de open space con Lisa Heft hace unos años, donde nos enseñó el poder de este formato. Desde entonces lo he realizado en varias organizaciones, no para compartir conocimiento únicamente, si no para trabajar en grupo en un propósito compartido. Es en ese contexto donde el Open Space revela su verdadera fortaleza como proceso. Un Open Space como motor de la transformación organizacional.

Como ejemplo, el Open Space Technology es introducido en la Sociocracia 3.0 como patrón de Open Space para el cambio, y en las "estructuras liberadoras" como estructura para liberar la acción y el liderazgo.

Es muy difícil que las personas lleguen a una conferencia con un propósito compartido, algo que les involucre y les haga sentirse partícipes, responsables de lo que vaya a suceder. Quizás por eso, podemos encontrar artículos como el reciente artículo (Conferencias Open no lo son)  que apunta a las deficiencias del uso que se suele hacer del open space como método de (des)conferencia. Básicamente, una conferencia no dejará de ser una conferencia por mucho que hagamos un formato diferente, si los asistentes no van más que a escuchar o a presentar sus transparencias. Recuerdo algún Agile Coach Camp muy poderoso, en formato Open Space, justamente por que percibes la conexión y creación de comunidad en un evento. Justo cuando había un nexo común y real entre los asistentes.

Los amigos de Biko2 me invitaron a escribir un artículo sobre el Open Space en su revista Biko Insights. Es un artículo que expande estas ideas, lo puedes encontrar en https://www.biko2.com/insights.

El Open Space es un tipo de proceso para generar ideas y posibilidades, divergente, no para crear planes de acción.

El propósito

Si en tu organización os enfrentáis a un reto, y queréis hacer una fórmula participativa, el Open Space es el formato a probar. Si un grupo se enfrenta a cambios en los que debe alinearse, escucharse, y tomar acción, una posibilidad es decirles lo que hacer. Quizás alguien puede tener la autoridad (formal) para hacerlo, pero el cambio va a ser muy difícil así. El cambio que viene de la auto-organización es más poderoso y probable que suceda. Si las personas creen en las razones del cambio y lo pueden elegir.

Quizás estés preparando la estrategia de los próximos años, una transformación interna, o nuevos mercados. De la diversidad del grupo y los diálogos que enriquezcan las diferentes visiones podremos obtener visiones con más perspectivas y más compromiso.

El formato Open Space es interesante para generar conferencias más participativas. Pero es realmente PODEROSO cuando el grupo de personas se une alrededor de un propósito al que han sido invitados a participar.

La conexión: la invitación

Antes de realizar un Open Space debe estar muy claro el propósito del mismo, y las implicaciones del mismo una vez que arranque. Como facilitador tendrás que sostener el espacio (hold the space), pero debes tener la autoridad para hacerlo anteriormente. El Open Space genera una espacio donde todas las voces y opiniones podrían ser oídas. Si el sponsor del evento, o los managers de la organización no están dispuestos a que eso suceda, es mejor no empezar. No se puede iniciar un Open Space con limitaciones a lo que pueda decir la gente invitada.

La conexión se genera por la invitación, un Open Space no puede ser un evento obligatorio, básicamente por que sus propias reglas internas contradecirían la obligatoriedad. La invitación se genera alrededor de un tema central, que recoge el propósito, y que se expresa como la causa de la invitación.

En una transformación la invitación lo es todo. No cambiamos por que nos digan que lo hagamos. Cambiamos cuando decidimos hacerlo, así que invitemos a quién quiera trabajar en ello. Y un Open Space no puede ser obligatorio, pero crea el espacio perfecto para las personas a las que une un propósito.

La preparación

Facilitador y sponsors del Open Space deben acordar el tema, entender las reglas, elegir la duración y seleccionar los invitados. Además, se debe elegir un lugar que permita reunir a las personas sentadas en círculo para el inicio y cierre del evento, así como varios espacios modulares dónde se irán produciendo las charlas.

La duración

La duración mínima de un Open Space es de 4 horas, donde nos da tiempo a preparar la parrilla de sesiones, realizar 3 sesiones de una hora cada una, y un cierre breve. La recomendación es que cada sesión debería durar al menos una hora, como tiempo mínimo para que un grupo tenga un conversación profunda sobre el tema que quieren tratar. Un Open Space puede ser de varios días, cuando la invitación gira alrededor de un tema muy complejo o conflictivo. Las pausas entre días permiten asentar las ideas, reflexionar y llegar al nuevo día con más ideas y perspectivas.

La introducción

¿Quién ha oído hablar jamás de un "cuadrado de amigos"? El círculo es la geometría fundamental de la comunicación humana.

Todas las personas inician el día del Open Space sentadas en círculo. Este es un elemento importante en la facilitación del Open Space, pues indica la igualdad entre todos los participantes del mismo. No hacen falta introducciones ni presentaciones, es un tiempo demasiado valioso y por tanto un coste demasiado elevado. Las conexiones entre la gente surgirán por el interés común en el tema común. Conectamos a través de temas o conversaciones, no por las introducciones, títulos o posiciones.

El sponsor debe recordar brevemente el tema del Open Space, la razón de que estén todos invitados, y el facilitador abre el círculo explicando a continuación las reglas del Open Space.

Los principios y la ley del Open Space

La Ley de los dos Pies, o de la responsabilidad y el movimiento: Si en un lugar o momento no te encuentras contribuyendo o aprendiendo nada significativo para ti (responsabilidad), debes utilizar tus dos pies (movimiento) para encontrar ese lugar más productivo donde mostrar la luz que te corresponde.

¿Imaginas una organización dónde las personas están allá siempre dónde creen que más pueden aportar, o más les aportan, guiadas por un único tema central y completamente alineadas? Esa es la sensación cuando un Open Space funciona bien.

Además de la Ley de los Dos pies, hay cuatro principios que rigen el evento también:

Ley de los dos pies

  • Cualquiera que viene es la persona adecuada.
  • Cualquier cosa que pudo suceder es lo único que podía haber pasado.
  • Cualquier momento en el que empieza es el adecuado.
  • Cuando se acaba, se acaba.

Estos principios dan a entender que las personas están por encima del proceso. Sin embargo, estos principios no dan cabida a un "todo vale", y es labor del facilitador mantener el espacio abierto, sin que por ejemplo se manipule la asistencia de las personas a una sesión u otra, o ley de los dos pies como decisión individual de responsabilidad y movimiento.

El marketplace

Tras asegurarse el facilitador que las reglas están claras, se crea la parrilla de sesiones. Se establecen las duraciones y el número de sesiones en paralelo dependiendo del número de personas. Al menos, cuatro sesiones en paralelo por cada 100 personas.

Cada persona que quiere presentar una sesión escribe el título de la misma y su nombre en una hoja y la presenta desde el centro del círculo al resto de participantes. Posteriormente la coloca en la parrilla de horarios.

Una recomendación que daba Lisa Heft era que no hubiese ni filtros, ni priorizaciones ni agrupamientos. La diversidad es muy importante en un proceso divergente, y cada sesión puede ser diferente completamente aunque traten el mismo tema, pues tiempo, personas, emociones e ideas son diferentes alrededor de las sesiones. ¡Siempre hay tiempo y lugar para alguna sesión más! La agrupación tiende a crear pensamiento único. Como facilitador no podemos decidir sobre este tema, pero sostén el espacio para que entiendan su repercusión.

El facilitador

La labor del facilitador es mantener el espacio. La facilitación del Open Space es especial, es un evento altamente auto-organizado, sin embargo, las pequeñas intervenciones de un facilitador pueden arruinarlo o hacer que fluya. Mantener el espacio es un concepto que llama a observar, cuidar y atender a los participantes y sus interacciones, más que trabajando con ellos, trabajando con el espacio, con el contexto que se crea alrededor.

El concepto es el de la no-intervención consciente. No puedes tomar decisiones por el grupo, pero debes de ser consciente del impacto como facilitador, estar presente, y cómo esta presencia puede influir. El facilitador confía en el proceso y las personas. Además, es importante estar atento a la diversidad del grupo, que esté atendida, tanto la visible (Idiomas, sexo,...) e invisible (discapacidades, clases sociales,...).

Las sesiones y el espacio

Se debe mantener un lugar de noticias e información, especialmente si el Open Space es largo, para mantener cualquier cambio logístico. Además, las comidas y los descansos tienen que suceder en el mismo lugar, de manera continua con las sesiones, para no romper el foco y el flujo de ideas.

De cada sesión debe salir un resultado, para que quede constancia del trabajo realizado. Unas conclusiones, un resumen de la conversación, unas posibilidades a investigar,... es importante que este trabajo quede para que tras el Open Space se pueda seguir trabajando en la línea que el grupo vaya creando.

El cierre

El grupo vuelve al círculo y el facilitador invita a reflexionar sobre el transcurso del Open Space. Dependiendo del tiempo disponible se puede dar más tiempo de compartir experiencias, o puede ser un cierre más rápido, como compartir una frase o una palabra con el grupo.

El facilitador debe recoger las palabras de cierre, pues constituyen una visión del grupo sobre el proceso y el trabajo realizado, que posteriormente rescatará el espíritu del Open Space realizado.

Después

Tras un Open Space tenemos toneladas de información y energía. Es responsabilidad de la organización canalizarlas y seguir trabajando con las personas. El facilitador debe recoger la información generada de cada sesión, compartirla y distribuirla entre todas las personas, especialmente si forma parte de una transformación. Además, realizar una evaluación con los sponsors sobre el resultado y el proceso en sí mismo.

Referencias

Volver
Volver
TAYARI LAB
11.03.2019

Diseño organizacional

por: admin
diseno organizacional

Cuando diseñamos nuestras organizaciones, ¿en base a qué lo hacemos? ¿Sabemos que nuestras creencias o visiones del mundo limitan nuestra capacidad de toma de decisiones? Antes de entrar en los detalles del diseño organizacional, debemos ser conscientes de nuestras creencias.

En un entorno complejo como en el que nos movemos hoy en día, -entornos VUCA: Volatil, Incertidumbre, Complejidad y Ambigüedad- no nos podemos regir por las mismas reglas que nos han funcionado hasta ahora. Nuestras creencias sobre cómo deben ser nuestras organizaciones limitan o influencian nuestra capacidad de adaptación.

Teoría X/Y

Como ejemplo de creencia limitante, miremos la teoría X/Y de McGregor (“The Human side of the enterprise”, 1960). Esta teoría nos habla de dos imágenes que tenemos de las personas en nuestras organizaciones.

  • Las personas X: que no les gusta el trabajo, que deben ser forzadas a realizarlo mediante premios o castigos, que evitan las responsabilidades.
  • Otra la persona Y: sobre personas que necesitan trabajar, motivadas, que se auto dirigen hacia los objetivos y que aceptan responsabilidades.

X-Y-McGregor-Betacodex-es

McGregor nos dice que solo una es “verdad”. Todos somos Y, pero tenemos prejuicios sobre cómo vemos a las otras personas, y creemos que son como X.

En nuestros talleres sobre diseño organizacional hacemos un ejercicio que nos muestra cómo los asistentes identifican estos porcentajes altos (típicamente más del 40%) de personas X, ¡mientras que en en la sala lo habitual es el cero por ciento! La verdad es que el comportamiento de una persona no depende sólo de su naturaleza, si no también de su contexto. Y ese contexto en una organización, depende de nuestro diseño de la misma: jerarquías, evaluaciones, sistemas de bonus, salarios, etc.

Si tomamos nuestras decisiones de diseño organizacional basados en nuestra creencia de que las personas tienen un comportamiento X, obtenemos organizaciones orientadas al control. En ellas tratamos de controlar a las personas que se escaquean, desanimadas y que no quieren responsabilidades. Pero, ¿qué tipo de comportamientos generan esos sistemas? Precisamente los que pretendíamos evitar. Obtienes lo que inviertes: personas que sufren con el control, que solo les preocupa la conversación económica y que no van a asumir responsabilidades.

¿Qué hacemos con sistemas que generan comportamientos X? Nos esforzamos en encontrar personas motivadas y responsables para nuestras organizaciones,… y luego les sometemos a esos sistemas organizativos que tratan de controlarles. ¿qué podría suceder con ellas? W.E. Deming decía: “Un mal sistema derrotará a una buena persona siempre”.

Creencias

La falta de control no implica caos o ineficiencia. Moverse a una organización que aprende, implica generar alineamiento y colaboración de manera diferente en aras de un objetivo compartido, el de la organización. La organización se debe adaptar a la demanda, al contexto y la propia cultura existente. Probablemente no existe un sistema perfecto que podamos exportar de organización a organización, si no que hay que descubrir y aprender con él.

Estas son algunas otras creencias (por John Cutler) que podemos explorar para crear nuestros sistemas. ¿en qué lado nos situamos en nuestras creencias? ¿qué sucedería si nos movemos hacia creencias diferentes?

creencias-tradicionales-vs-nuevas

Si nuestro modelo organizacional no es eficiente la organización no consigue acercarse a su propósito. Pero los mercados cambian, y los propósitos evolucionan. Las organizaciones actuales deben adaptarse más rápido y más efectivamente a todos los cambios que suceden en su exterior y las creencias tradicionales nos conducen típicamente hacia organizaciones más burocráticas, difíciles de cambiar y dónde la innovación y creatividad son las excepciones.

Este es el taller completo, añadiendo conceptos de Sociocracia 3.0:

Volver
Volver
TAYARI LAB
Charla presentada en itSMF Euskadi 2018

el niño de los principios ágiles

La imagen del Niño Interior es un símbolo mental, que conecta directamente con todos estos recuerdos infantiles. Infantil no es algo peyorativo, pues es muy positivo tener la creatividad, la espontaneidad del niño, y es maravilloso seguir sintiendo su capacidad de asombro ante los misterios y sorpresas de la vida.

Qué es el niño interior

El manifiesto ágil va a cumplir 18 añitos. Y me preguntaba qué tal habría pasado la adolescencia. Agile nació como un manifiesto, una proclama realizada en un momento muy concreto. La complejidad del desarrollo de software, los mercados y el desarrollo de producto no se podía seguir gestionando con métodos basados en supuestos mecanicistas.

Lanzamos productos en 2014, con procesos de sw. de los 70s, con técnicas de gestión de los 20s

Expectativas

Así que todos pusimos las expectativas realmente altas con el movimiento ágil. Por fin parecía que habíamos encontrado cómo desarrollar software: teníamos principios ágiles, creando espacios seguros para los desarrolladores, las prácticas técnicas de XP,… y sobre todo, investigando aún más cómo hacerlo. Por que en el fondo, como arranca el manifiesto, aún estamos descubriendo maneras de hacerlo. Existía una necesidad de aprender, que estaba siendo satisfecha por una comunidad creciente y cada vez más potente.

La niñez

De niños todo es muy sencillo. Simplemente así nos lo decía Tobías Mayer en la CAS2013, de Bilbao. Agile es así:

[[make, align]*, deliver]*

Y la comunidad se puso a experimentar… ¿qué te funciona? ¿qué técnica usas para esto? ¿y para lo otro? Nos volcamos a hacer experimentos para encontrar a cada uno lo que le funcionaba en su contexto. Nos paramos, reflexionamos y volvemos a probar mejorando. Compartir con la comunidad era una fuente inagotable de experiencias y aprendizajes e ideas.

Los adultos

El mundo real™ en seguida se adaptó al agilismo:

Chiste Dilbert 1 Chiste Dilbert 2

O no… quizás adaptaron el agilismo al mundo real™…

La adolescencia

Así que esta fase crítica de la agilidad, para formar un adulto responsable, se tornó en dificultades que quizás el niño-adolescente no supo solucionar.

Lista de impedimentos a Agile

Tantos problemas tenía que se tornó rebelde y se adaptó como pudo al mundo real™

Modelo SAFe vs principios ágiles

Y lamentablemente, algunos de los buenos amigos del agilismo incluso le dieron incluso la espalda, al tomar caminos diferentes.

comunidad software craftmanship

Así que ahora el agilismo se debate entre conflictos internos ante la adaptación al mundo real™ y el espíritu rebelde y sus valores de la infancia.

¿Quién es el niño interior ahora?

¿Qué tengo la impresión que hemos dejado de escuchar, qué representa ese niño interior? Los principios ágiles.

Los cuatro principios ágiles básicos: personas, inspeccion y adaptación, el manifiesto y las prácticas técnicas

  • Personas: Siendo la colaboración la palabra clave, dejemos que las personas que sufren un proceso, hacerse dueños de él, y responsables de mejorarlo. Creemos las organizaciones para ellas.
  • Inspección y adaptación: No hay una «bala de plata» en este mundo complejo. Cada contexto necesita una aproximación diferente.
  • El manifiesto ágil: Los principios básicos que fundaron el movimiento.
  • Atención a la calidad técnica: Si desarrollamos software, necesitamos la comunidad de la «artesanía del software». La calidad no es negociable.

 

Así que acabé la charla proponiendo tres retos a los asistentes. No como objetivo, si no como reflexión, ¿qué nos impide hacerlo? Por que no podemos culpabilizar «a lo ágil», no es un niño que ha crecido por si solo, la comunidad y el mundo empresarial le hemos dado la forma actual. Plantéate estas cuestiones:

  1. Software funcionando cada semana
  2. Consigue que desde stakeholders a programadores tengan espacios de comunicación –feedback-
    fluidos sobre el producto.
  3. Implemente equipos multidisciplinares y auto-organizados, dueños de sus procesos.

Y a ti, ¿qué te dice tu niño interior? ¿cómo volvemos a los principios ágiles? 🙂

(Presentación utilizada)

Volver