Tendencias

Agilidad el reto de las organizaciones

0

Melvin García, Guatemala.

Ágil no es rápido 

El agilismo nos ha vendido la idea de que ágil es rápido, pero no necesariamente es así. El agilismo se basa en la experimentación, es decir; pruebo en la primera iteración, si veo que me funciona, sigo; si no me funcionó lo deshecho y empiezo nuevamente. Muchas veces en un proyecto ágil podemos llevarnos más tiempo que si lo hiciéramos de manera predictiva, llevar a cabo el proyecto de una manera predictiva nos permite dibujar el escenario al que queremos llegar, pero en un proyecto ágil vamos a prueba y error, lo que nos permite ir aprendiendo.

¡Apresurarse a cometer el error!

La metodología ágil nos dice apresurese a cometer el error para entender rápidamente y aprender de él lo antes posible, ya que esto normalmente lleva mucho tiempo.

Hacer partícipes a todos los interesados. 

Esto hace parecer que vamos avanzando muy rápido, y el proyecto tiene mejores resultados aplicando las herramientas ágiles. 

Ejemplo: En la fabricación de una botella, yo le muestro al cliente avances y le comparto como quedó la boquilla, el efecto de esto será la retroalimentación temprana del cliente, podrá hacernos ver si es lo que esperaba y comenzará a sacar sus propias conclusiones visualizando el producto mínimo viable (MVP-Minimum Viable Product), es decir puede ir pidiendo modificaciones y avances. Esto es una de las grandes diferencias contra el modelo predictivo ya que en este pueden pasar 6 meses antes de que el cliente pueda conocer el proyecto o producto y que al verlo pueda rechazarlo al no ser lo que esperaba y caeremos en reprocesos y tiempo perdido. Por eso es que Ágil no es que sea más rápido, sino que podemos estar viendo mayores resultados porque formamos parte en cada uno de los entregables, de las historias que estamos terminando, nos reunimos con el equipo, posteriormente con el Product Owner, e incluso hacemos una demostración de nuestros avances, razón por la que pareciera que vamos más rápido.

Yo como un ser integrador

El efecto de esto es que las barreras comienzan a caerse y dejamos de trabajar bajo el concepto de “látigo” con asignación de actividades sobre las cuales se actúa como capataz en las que estamos detrás de la gente presionando para que concluyan sus tareas y ¡cuidado si no terminan a tiempo!. Cuando en realidad se debería tener la convicción de “Yo como ser integrador del equipo” lograr acciones que mejoren no en lo individual sino como equipo.

El reto de las organizaciones

El marco de trabajo ágil, es sumamente sencillo de entender, no tiene ciencia. La ciencia en sí, está en el trato con los individuos, en gestionar a cada uno de ellos, por separado, y entender las necesidades de mis stakeholders directos e indirectos, aquellos que afectan el proyecto o le van a permitir llegar al éxito

Rompiendo barreras

Esa gestión individual es lo complejo por lo que es importante empezar a trabajar con el equipo para fortalecerlo, hacer alianzas con los miembros del equipo donde todos tengan claro que buscamos un ganar – ganar compartiendo nuestro liderazgo y rompiendo barreras, mismas que muchas veces son puestas por los mismos miembros del equipo. Comprendamos pues, que el jefe o líder puede por ejemplo, trabajar con nosotros una priorización y nosotros a la vez, podemos participar sin que el nos delegue.

2 Cosas que debes considerar:

· La cultura organizacional es una de las principales barreras a las que te enfrentarás si vas a integrar prácticas ágiles a tus proyectos. Debes definir una estrategia para esto. · No todos los proyectos se pueden dirigir bajo un enfoque ágil, es importante ser consciente de esto.

Scrum Escalado

Se puede aplicar a los proyectos dependiendo la estructura de la institución, es un gran mito pensar que solo aplica para proyectos pequeños, el framework nos dice que los equipos -pueden manejarse de 3 miembros o de 7 +- 2 y en máximo de 9 (dependiendo de la casa certificadora), podemos tener equipos subdivididos de tal manera que en un proyecto grande lo podamos subdividir en mini proyectos y manejarlos con Scrum escalado es decir; a nivel Programa y Portafolio podemos tener proyectos ágiles de tal manera que asignemos un equipo para cada uno de nuestros proyectos y en lugar de tener la Daily meeting con todos los miembros podemos llevar la reunión Scrum of Scrum (SoS) que no es más que reuniones con los scrum master para conversar sobre la situación de los proyectos en lo individual

Rocío Ríos comparte su experiencia sobre la Dirección de proyectos

Artículo anterior

Barreras de Agilidad

Artículo siguiente

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *