Un cambio afecta más allá del producto. Afectará al organismo, a sus moléculas y a sus átomos.
Durante los últimos años las empresas del sector tecnológico e industrial están sufriendo un cambio muy brusco respecto a sus bases organizativas. La transformación va más allá de lo digital. Estamos transformando los proyectos, los procesos, los equipos, las personas y la cultura de esas personas.
Últimamente parece que no se pueda contemplar un proyecto sin tener que aplicar metodologías Agile, tener un equipo Scrum o inculcar una mentalidad Lean. Y a ver, en cierto modo, no hay que negar que revisar los modelos organizativos que tenemos actualmente es necesario. Pero quizá estamos tan centrados en aplicar la metodología en sí que dejamos para lo último cómo afecta todo ello a nuestros equipos, las personas. En muchas empresas se está viviendo una revolución respecto a la actitud de sus empleados. Hoy en día son más exigentes, hay más rotación, quieren participar más en las decisiones, etc… La sociedad está cambiando, los procesos están cambiando, las personas están cambiando y nuestra obligación, es estar a la altura de ese cambio.
Fuente: "Managing performance in agile teams"
Un nuevo concepto de equipo
La imagen refleja la transformación organizacional del concepto de equipo. Pasamos de una organización en cascada a una estructura molecular.
Por tanto cambia la estructura, cambia la forma en la que nos relacionamos y cambia la diversidad de modelos en función de cada necesidad.
Hay que entender que un cambio afecta desde la base hasta la punta del iceberg. Lo que sería desde una visión física: toda acción tendrá una reacción. Y cuantas más reacciones controladas tengamos más evitaremos el Big-Bang.
¿Cómo está afectando a las personas y equipos la transformación de nuestros procesos hacia metodologías ágiles?
La apuesta por estos modelos de trabajo tienen una gran incidencia en cómo nos organizamos, cómo lo vivimos y las skills y viviencias de cada persona.
A continuación muestro algunas ideas problema-solución que pueden ayudar a crear un entorno más cómodo con nuestros equipos frente a tal transformación.
CASO 1: SEGURIDAD PSICOLÓGICA
Síntoma: Los equipos sienten miedo de ser juzgados a la hora de plantear ideas o inquitudes. Su rol es recibir información pero tienen baja interacción con el proyecto. Como consecuencia no solo se aporta menos valor si no que el equipo no se siente involucrado o integrado.
Solución: La seguridad psicológica es un término que nace en la Escuela de Negocios de Harvard y que posteriormente se descubrió que era el la clave del éxito en la gestión de los equipos en el Proyecto Aristóteles de Google. Crear seguridad se trabaja fomentando la confianza. No solo es importante transmitir esa confianza sino ayudar a que los equipos la tengan en sí mismos. Podemos pensar en diversas herramientas para ayudar a crear un entorno seguro y cómodo. Recomiendo leer el apartado «Tool: Foster psychological safety» del Proyecto Aristóteles de Google dan algunas ideas.
Caso 2: GESTIÓN DE LA Incertidumbre
Síntoma: A veces los equipos se muestran desconcertados al tener que realizar una acción que no entienden su necesidad o qué valor aporta. Se interpreta como un capricho del product owner o cliente. Esto no solo les genera incertidumbre e inseguridad sino también frustración y desconcierto.
Solución: Este problema puede tener diferentes casuísticas por lo que en primer lugar, escucha a tu equipo. Van a necesitar explicar su opinión y visión y quizá estén llegando a un punto que aún no se había visualizado. Al dejar que tu equipo exprese su opinión ante una petición interpretada como incoherente o innecesaria, integrarás a tu equipo en las decisiones del proyecto. Ese debate dará la oportunidad de darles más detalles de por qué es importante esa petición y cómo ayuda desde una visión más global. Incluso podrás ayudarles a encontrar nuevas soluciones que satisfagan la misma necesidad mediante el diálogo.
Caso 3: Falta de foco en el sprint goal
Síntoma: Les cuesta marcar los objetivos por sprint, piensan en el Product Goal en vez de en el Sprint Goal. Hacen trabajo de más o tareas que no se necesitan.
Solución: Se les tiene que ayudar a marcar el foco y explicarles el alcance. Ayúdales a entender que los castillos se construyen con cada piedra, que está bien pensar en el producto acabado pero que este puede sufrir adaptaciones a lo largo del proyecto.
Caso 4: adaptación a la velocidad del proyecto
Síntoma: Los equipos no se adaptan o entienden la velocidad del proyecto, lo interpretan como desorden, caos o falta de información.
Solución: Transparencia en el proyecto. Muestra el mapa del proyecto y comparte con el equipo el Sprint Planning. Que vean de forma clara el alcance y el tiempo que se necesita para llegar al objetivo. Ayúdales a medir el esfuerzo en función del tiempo del proyecto para no tener pérdidas de energía que generan frustración.
Caso 5: percepción de las iteraciones
Síntoma: Muchas veces percibimos los procesos con un inicio y un fin. Cuando se cierra una decisión cuesta volver a valorarla o iterar porque se percibe que el esfuerzo ha sido en vano si se vuelve a abrir o agobia la falta de tiempo para esa nueva iteración. Lo frecuente es procrastinar esa iteración o tener una actitud negativa ante la petición de cambio.
Solución: Intenta transmitir que un producto estará cerrado y terminado cuando ese producto esté obsoleto. Mientras exista el producto, siempre será susceptible de mejorarlo e interarlo. Esto enlaza con el concepto de Mejora Continua. Nunca nada ha llegado a su alcance perfecto, siempre se puede seguir trabajando en ello.
Un producto estará cerrado y terminado cuando ese producto esté obsoleto. Mientras exista el producto, siempre será susceptible de mejorarlo e interarlo.
Caso 6: GESTIÓN DEL EGO
Síntoma: Los equipos entienden que el éxito o fracaso es responsabilidad de la persona que ha ha llevado a cabo. Se generan sentimientos de propiedad, personalizar las tareas, comparaciones y rivalidades. Poner el foco en el propio ego puede hacer que se pierda el foco sobre el Product Goal. Además, el cliente se ha acostumbrado a determinada persona así que será reticente a cualquier situación que implique cambiar a esa persona.
Solución: Romper con la cultura de propiedad. Hoy día muchas organizaciones trabajan con equipos multi-proyecto. Los miembros pueden flotar de un proyecto a otro evitando la dependencia y personalización en los perfiles. Esto a nivel de gestión permite una flexibilidad totalmente positiva. En el framework Scrum donde se trabaja con equipos multifuncionales se remarca que nunca existirá la propiedad de una tarea. De este modo la responsabilidad siempre será de todo el equipo.
¡OJO: Trabajar con un modelo multi-proyecto también tiene enorme consecuencias que hay que controlar. Algunos ejemplos son:
Cuando trabajamos en 2, 3, 4.. proyectos a la vez perdemos tiempo de concentración entre uno y otro. Esto afectará al rendimiento.
También influye en la implicación de las personas. El esfuerzo cuando nos sentimos responsables es mucho mayor a cuando nos sentimos simples piezas de un puzzle. Aumenta nuestra motivación y aumenta la implicación. La clave, es no implicarlos solamente en la tarea, el proyecto, la cuenta o el cliente sino focalizarnos en lo necesario que es dentro del equipo y de toda la organización.
