Los 7 errores más comunes en una Adopción Ágil

Toda implementación ágil tiene sus grandes retos, sin embargo hay siete errores comunes que he descubierto en diversos proyectos de implementación ágil:

1. El Scrum Master como líder de proyecto / desarrollador

Algo que me preguntan mucho es, ¿Qué hace el Scrum Master?, se tiene la percepción en general de que este rol no desempeña un papel crítico en las implementaciones de agilidad y es muy común ver que como el “Scrum Master” no “trabaja”, entonces le dan una responsabilidad de líder de proyectos gestionando y dando seguimiento a las actividades del Development team. Otro escenario muy común es que el Scrum Master termina siendo parte del Development Team haciendo desarrollo de software u otras actividades del equipo porque: “tiene tiempo de sobra”.

Estas percepciones son equivocadas y el Scrum Master es un rol de mucha importancia que debe estar enfocado en facilitar y dar Coaching al Development team. A parte de ser quien más conoce de Scrum y de facilitar eventos, este rol lleva las siguientes responsabilidades que comúnmente las personas desconocen:

• Evangelizar a la organización en Scrum.
• Llevar sesiones one on one de Coaching con los integrantes del Development Team para mejorar su productividad.
• Sesiones de Coaching a nivel equipo.
• Conocer a los miembros del equipo y entender sus motivaciones intrínsecas y extrínsecas para influenciarlos positivamente.

¿Sabías que el Scrum Master puede estar en más de 1 proyecto a la vez?

2. Dirección no involucrada en la iniciativa

Este es otro problema común. La dirección quiere “agilidad” pero no sabe qué es la agilidad, no vive la agilidad y no se involucra en la iniciativa. Esperan que de forma mágica la empresa sea ágil manteniendo las estructuras jerárquicas, el comando y control y que de alguna forma todo ocurra. La realidad es que para llevar una buena implementación no es suficiente querer ser ágil porque la competencia lo está siendo. La dirección se debe involucrar al grado de comunicar, vivir y ser parte activa de la iniciativa, y gracias a su apoyo tendremos un mayor empuje de la iniciativa, un aliado con mucha influencia e interés, comunicación clara con el negocio y se evitará la duplicación de iniciativas.

3. El negocio alejado de TI

Imaginémonos en una gran empresa, con un proyecto piloto ya seleccionado que cumple con las características idóneas para comenzar a vivir la agilidad, contamos con un buen Scrum Master y ya tenemos al Development Team. Todo parece perfecto, a excepción de un pequeño detalle: El que puede ser Product Owner no tiene tiempo (por temas operativos) de participar en el proyecto, así que decidimos establecer a un analista (TI) con algo de conocimiento del negocio como Product Owner.

Este escenario me atrevería a decir que es de las situaciones que más se repiten en las empresas y es una situación de riesgo, ya que es importante contar con una persona clave que conozca del negocio y que tenga empoderamiento para tener una buena estrategia de producto.

Recomiendo que se identifique a un Product Owner de parte del negocio que pueda estar involucrado en la iniciativa y que conozca de la necesidad a cubrir. Si no tiene el suficiente tiempo para el desarrollo del producto, pueden ver alternativas como un analista de negocios de forma transversal, pero dejando claro al equipo que no es el Product Owner, más bien es un apoyo para él.

4. No hay una estrategia de gestión del cambio

Es una constante encontrar a personas que tienen poca / mucha influencia y poco interés en los proyectos de implementación de agilidad que harán todo lo posible para que este no tenga éxito. Y como dice la teoría de complejidad del caos: “un pequeño cambio puede tener un impacto tremendo en el sistema”, esto nos explica cómo una persona o un grupo de personas que no tienen el interés de cambiar, pueden revertir toda una iniciativa a su estado original. Por todo esto es de suma importancia trabajar en una iniciativa de cambio, y en particular recomiendo Lean Change Management para enfocarnos en comprobar hipótesis y experimentar sobre los cambios. También sugiero trabajar con la gráfica de difusión de innovación de Rogers para identificar a los diferentes tipos de “Adopters”, comenzar con los Innovators y establecer experimentos de cambio para todos ellos.

5. No se considera la importancia de establecer contratos agiles

Estamos conscientes que uno de los valores en Agile nos dice “Colaboración con el Cliente sobre Negociación de Contratos”, sin embargo esto no significa que no debamos dejar claros algunos aspectos previos a trabajar y más si vamos comenzando a pilotear esta nueva forma de trabajo. Algo que ocurre muy comúnmente es que los proyectos piloto arrancan con los contratos tradicionales en donde solo se favorece al cliente y se establecen cláusulas de penalizaciones muy duras que lo único que generan es fricción y desconfianza entre todos. Mi recomendación es que en toda implementación ágil, se considere primero establecer contratos para los vendors en donde exista flexibilidad, pago por Sprints, reglas de compromiso claras tanto para el cliente como el vendor y así se incentive una co-responsabilidad que nos lleve al Ganar – Ganar.

6. No existe un equipo de adopción fijo

Es de suma importancia establecer un equipo fijo que ayude en la implementación de la agilidad. Muchas organizaciones por querer ahorrar algo de dinero asignan solo a un responsable, el cual en muchas ocasiones ni si quiera tiene la posibilidad de estar full time en el proyecto y pierde el enfoque poniendo en riesgo el éxito de la adopción. Recomiendo establecer un equipo de 3 a 6 personas que lleve un marco de trabajo como Scrum para la adopción de agile en la organización.

7. Equipo auto-organizado milagrosamente

Creemos que por poner a 6 o 9 personas trabajando juntas obtendremos resultados milagrosos. La realidad es que tener al equipo en el mismo sitio por sí mismo trae beneficios, pero eso no garantiza que el éxito se mantendrá constante ni que el equipo mejorará con el tiempo. Trabajar con un equipo auto-organizado es mucho más difícil que solo juntarlos, tenemos que trabajar en conocer a cada miembro del equipo, sus habilidades, sus áreas de oportunidad, tenemos que trabajar en crecer su catálogo de hard y soft skills para formar team members con múltiples habilidades, que a mediano y largo plazo reflejen creatividad total, que se auto administran y que pueden hacer de todo un poco. Siempre pongo el ejemplo del Starbucks, si llegan a uno, podrán ver cómo la persona que sirve el café también cobra en la caja, limpia los baños y atiende a los clientes. En ese escenario todos hacen de todo y lo mismo debemos aspirar en los equipos de desarrollo.

Como podrán ver una transformación ágil es mucho más que solo reunir al equipo y comenzar a trabajar con Scrum, y es por esto que sugiero tomen en consideración estos siete errores comunes y realicen las recomendaciones que aquí les sugiero.

Y para concluir me gustaría preguntarles: ¿han vivido alguno de estos siete errores? ¿Qué experiencia han tenido? Los invito a escribir en los comentarios.