domingo, 16 de diciembre de 2012

#juguemOS: War Games (parte 4)

Tras el primer gran encuentro, el siguiente al que decidí asistir también transcurrió en la misma sala (la que se encontraba en la parte superior de las 3 plantas que componían Izada). En esta ocasión asistió más gente y nos dispusimos en un corro de sillas: esta vez tocaba hablar. Por el perfil de la gente que participaba, me di cuenta de que poco o nada podía aportar a la conversación, no obstante, sí que me pareció interesante oír lo que aquellas personas que trabajaban diariamente con equipos se tenían que recomendar los unos a los otros.
La charla giró alrededor de una idea: cómo introducir al agilismo a aquellas personas que se resistían y remaban en dirección opuesta. Para ello, se plantearon dos casos reales:

  • Un equipo dentro de una organización con rencillas personales, acostumbrados a trabajar a su aire y cerrado al cambio agilista que se estaba gestando en la empresa.
  • Un equipo con un miembro saboteador que se resistía a trabajar en Scrum junto con el resto del equipo, que ni siquiera acudía a las daily meetings y que entregaba el trabajo a los 6 meses sin otro tipo de interacción con sus compañeros.
Sobre estas bases, se plantearon varias sugerencias con la intención de integrar a estas personas en la organización sin tener que recurrir a amenazas ni a salidas de tono que pudieran producir una situación de no retorno.

Una primera idea sobre la que se trabajó era que en vez de imponer este cambio, debía ser el propio equipo el que propusiera esta metodología. Para conseguir esto, el facilitador tiene que ejercer un 'arte' que mediante preguntas y acciones sutiles ponga de manifiesto los errores que se están cometiendo y que promueva la aportación de ideas para solucionar esto, guiando la conversación a la propuesta que buscamos. Con esto, lo que conseguimos es que en lugar de encontrarnos rechazo sobre una idea, el equipo la defienda y se comprometa con ella al considerarla suya.
El conocimiento de la metodología es fundamental para evitar el rechazo. Integrar a uno o varios miembros del grupo en otros equipos en los que se este llevando a cabo esta dinámica puede favorecer la comprensión y la posterior aplicación del agilismo. Hay que tener cuidado sin embargo de que produzca un efecto contrario de rechazo por considerar al equipo Scrum demasiado engreido o aleccionador. Se llegó a plantear incluso el cambio de organización del grupo, disolviéndolo al menos temporalmente para que trabajasen separados y realizaran una simple reunión de especialistas en su ámbito a la semana.
Obligar en cierta dosis a los trabajadores a asistir a las daily meetings y a otros eventos de la dinámica es completamente aceptable, como obligar a cumplir un horario. Se supone que la integración aunque sea a desgana permitirá que algo vaya arraigando. Si la persona se vuelve hábil en boicotear el encuentro, el facilitador debe promover la presión de sus propios compañeros para evitarlo y responder con técnicas aún más ingeniosas para contrarrestarlo; prometo publicar algunas técnicas según el tipo de personalidad en otra ocasión ;)
En contraposición, también se incidió mucho en que no era bueno tener un superior sobre el equipo, sino que debía autogestionarse y autoregularse en la medida de lo posible. Se habló de la transmisión y el intercambio de conocimiento que debía ejercer el Scrum Master, por encima de la autoprotección del terreno. Se hizo un simil con la edad media cuando los maestros artesanos transmitían todos sus conocimientos a sus aprendices (aquí debo mencionar también a Platón y compañía, porque si no mi novia  filosofa de vocación, me lo recriminaría). Más importante que el orgullo es la mejora continua, si alguien lo hace mejor que tú, asume sus técnicas frente a las tuyas como mejores y emplealas.
En definitiva, diversas ideas para solucionar un mismo tema que permaneció abierto y que fue muy interesante psicológicamente. En otro espacio, tratamos también como convencer a una persona de la conveniencia de una idea, por lo que pronto hablaré más al respecto aportando una técnica facilmente trazable en Kanban :)

No hay comentarios:

Publicar un comentario