Netmind - loader

Implantando Agile: barreras personales (parte 2)


Netmind - Implantando Agile: barreras personales (parte 2)    Artículo | Agile Development
| 21/05/14

En un post anterior comentamos tres de las principales barreras que a nivel organizacional podemos encontrarnos al tratar de difundir o implantar Agile. En este post vamos a complementar lo ya explicado con algunas barreras que podríamos clasificar como ‘personales’.

Confundir el éxito de Agile con el conocimiento de prácticas ágiles.

Para mí es uno de los principales factores a tener en cuenta al implantar Agile en una organización, evitar ‘perderse’ en las prácticas ágiles. Es frecuente notar que muchos miembros de los equipos ágiles se conforman con el conocimiento de las prácticas ágiles y el poder emplearlas en sus proyectos (realizar stand-up meetings, usar Kanban, etc.).

No es suficiente: Las prácticas y técnicas ágiles, si no existieran, cada equipo las volvería a crear. No es eso lo que hace ágil a un equipo. Se trata de la orientación al cliente y al producto, de la generosidad con nuestros compañeros y de sentir que constantemente estamos aprendiendo.

Confundir la posición en una empresa con la posición en un equipo.

En los equipos y empresas de nueva constitución es menos frecuente, pero es un problema recurrente en organizaciones que comienzan a adoptar metodologías ágiles. A veces cuesta que alguien que siempre ha estado en un plano jerárquicamente superior al resto de miembros de su equipo ahora se distancie y adopte un perfil más ‘colaborador’.

El centro de Agile son los equipos, y las relaciones entre sus miembros. Es recuperar a las personas en los equipos y olvidarnos de ellas como ‘recursos’. Y esto es, en ocasiones, muy difícil de interiorizar en ciertas organizaciones.

Confundir el valor global de los proyectos con el valor personal que obtenemos de ellos

Cuando afrontamos nuevos proyectos inevitablemente pensamos en qué nos aportará a nivel personal, qué aprenderemos, qué podremos experimentar, etc. Hasta aquí esto es obviamente legítimo y correcto, pues debemos motivarnos orientándonos hacia el aprendizaje continuo. Ahora bien, de nuevo es el proyecto como un hecho colectivo lo que debería imperar en nuestras valoraciones: aprendizaje sí, pero buscando un valor para el conjunto del equipo.

Si ciertas personas en los equipos manifiestan que ‘no aprendemos nada en este proyecto’ o ‘ojalá hubiéramos podido hacerlo en otra tecnología’, etc…lo que dan a entender es que el proyecto no es 100% motivador para ellos, y esta sensación puede ser contagiosa. Las armas para luchar contra ello de nuevo son hacer prevalecer el bien común del proyecto sobre intereses particulares, así como poner sobre la mesa ya desde el inicio de los proyectos el ‘valor’ de lo que queremos obtener como equipo en el mismo.

En posts siguientes iremos avanzando en mecanismos para cohesión de equipos y en otros problemas con los que podemos encontrarnos al implantar Agile.

Links de interés sobre Agile

Formación Agile

Vídeo: El rol del Project Manager en entornos ágiles

Vídeo: Scaled Agile Framework para grandes organizaciones


Entradas relacionadas
Nuestro sitio utiliza cookies para análisis. Si no estás seguro de ello, echa un vistazo a nuestra política de privacidad.