Ser ágil es …

Si hay algo que aprendí en el último año es que la frase con la que titulé esta entrada es una de las cosas más difíciles de explicar que me encontré en el último tiempo.

Estas semanas estuvimos hablando mucho en el trabajo sobre agilidad, equipos, ser ágiles, Scrum, etc; y algo que he notado es que cada uno interpreta diferentes cosas sobre el qué y el cómo. Y en general me es muy difícil explicar la “particular” mirada que tengo actualmente de lo que entiendo por “ser ágil”.

Sacada de http://pragmaticprojectleadership.com/agile-mindset-deciding-work/

Hasta hace poco mi definición más corta para responder a esta pregunta era “ser ágil es responder rápido al cambio”. Después de largas horas de charlas durante el Agile Open Camp de este año, me di cuenta que mi respuesta no me dejaba satisfecho.

¿Somos ágiles porque hacemos iteraciones?, ¿somos ágiles porque hacemos entregas continuamente?, ¿somos más rápidos por ser ágiles?, ¿somos ágiles porque usamos Taiga, Jira, Trello?. Hay ejemplos y contra ejemplos a montones que responden estos interrogantes en varios blogs.

Para mi “ser ágil” representó un cambio mental, un enfoque diferente a lo que estaba acostumbrado a hacer. Y ese cambio mental es simplemente la búsqueda de la agilidad, no el ser ágil en sí. Ágil es un ideal. Un lugar donde queremos llegar. El camino para ir a ese lugar es lo que creo que nos convierte en agilistas. Y en ese camino no hay solo procesos y herramientas, hay personas. La forma en que interactuamos con las personas es la que nos acerca al objetivo.

El ser ágil plantea una perspectiva, una dirección hacia donde queremos ir. El Manifiesto ágil lo plantea muy bien en sus primera palabras

We are uncovering better ways of developing software …

Ser ágil se trata simplemente de eso. Buscar mejores formas. ¿Scrum te funciona? Genial usalo! ¿Kanban es más lo tuyo porque no podes planificar por iteraciones? Excelente, usalo! Experimentá, buscá tu espacio y tratá de ir evaluando y mejorando constantemente en busca de ese ideal ágil.

En uno de los proyectos donde estoy involucrado estamos atravesando justamente esta transformación. No usamos Scrum; no usamos Kanban; no hacemos XP; ni RUP :D. Pero sí implementamos varios cambios que buscan mejorar la forma en la que creamos el producto para el cliente.


Hablamos entre todos

El primer cambio que acordamos fue dejar de lado los chats uno a uno y nos ‘forzamos’ a hablar en el canal de Slack del proyecto.

Lo que nos venía pasando es que caía un ticket a resolver, lo tomaba alguien del equipo, consultaba con otra persona del equipo, llegaba un pedido para que se revise el código y acto seguido quien revisaba preguntaba : “¿pero no podemos hacerlo de esta otra forma que es más simple?”.

En general uno encuentra que siempre había una alternativa menos costosa que uno no pensó. Nos estábamos perdiendo la parte de la interacción de las personas :).

Esto está ayudando mucho porque todos, aunque no estemos 100% del tiempo en el proyecto, podemos estar al tanto de lo que está pasando, opinar cuando ve que otro tiene un problema, o simplemente ofrecer otra perspectiva.

Un lado “negativo” que se genera es que gente que está de paso por el canal vea que hay “mucho ruido”. Si esto pasa recomiendo tener varios canales para el proyecto: uno de cosas casual / novedades y otro más movido donde se hable de todo, los bots peguen los resultados de las tareas automáticas, etc. También podemos sugerirle a esta gente la “regla de los dos pies” virtual :).

https://www.flickr.com/photos/planeta/3311035191

Y como cierre de este punto: hablen entre Uds a ver qué es lo mejor para este equipo en este proyecto. Júntense una o dos horas en una sala de reunión, plaza, bar, o donde les pinte y traten de encontrar el mejor canal para intercambiar información de manera efectiva.


Eliminamos distracciones.

El Manager, antes de los cambios, solía interrumpir por cada consulta del cliente a los desarrolladores para atacar diferentes tareas: dejar lo que se estaba haciendo para empezar una tarea nueva (dejando la actual por la mitad); investigar un bug para ver si es un problema grave; o simplemente para hacer de proxy con alguna pregunta del cliente.

Esto hacía que el cambio de contexto sea constante y la productividad y el ánimo decaía.

Para atacar este punto lo que hicimos fue co-crear una matriz de Eisenhower que nos permite priorizar las cosas en urgente / importantes. Para tener un criterio común y evitar ambigüedad definimos que lo importante es lo que el cliente quiere. Mientras que lo urgente es lo que afecta al usuario del sitio.

Con esta categorización pudimos acordar que solo lo urgente e importante puede ser tratado fuera de las reuniones de sincronización. Éstas reuniones las hacemos dos veces por semana : lunes y miércoles sobre las 14 hs (el horario es flexible).

Entonces, si llega un pedido del cliente, el Manager puede decidir si es necesario interrumpir el trabajo normal o si puede esperar a la próxima reunión, que en el peor de los casos es dentro de 48 hs.

Recién estamos viendo los primeros resultados y fueron en semanas bastante relajadas, pero me animo a decir que el equipo está más feliz, el cliente obtiene más cosas “terminadas” por semana y seguramente empecemos a bajar la tasa de tickets reabiertos por hacerlos apurados o desconcentrados.


A simple vista pueden parecer cambios triviales, pero el proceso de llevarlos a cabo no lo es. El trabajo que hace el equipo día a día para mejorar estos mismos puntos es increíble.

Me animo a decir que este es uno de los proyecto más ágiles en los que he trabajado últimamente :). Ah, y todo usando solo Redmine y Slack :D, las mismas herramientas que usábamos antes.

Encontrar el punto de equilibro no es fácil, sobre todo en una software factory. Quizás cuando trabajás en un producto se da todo más natural, pero no es imposible. Mi consejo acá es ir con cambios pequeños que no sean muy disruptivos a lo que ya está instaurado como cultura en la empresa y luego a medida que se vayan dando los resultados la gente se va a ir contagiando sola.

Para cerrar quiero dejarles algunas recomendaciones que he recibido y que busco aplicar en mayor o menor medida y que creo que pueden ayudar a cualquiera a empezar en el camino del agilista :

  • Comunica tus intenciones, con todos y a todos.
  • Trata de evitar las reuniones donde no esté todo el equipo, si hay algo anti-ágil para mi, es tener sub-equipos (si jugaron de chicos al teléfono descompuesto, sabrán de qué hablo :).
  • Mantené tu equipo en un tamaño razonable. Tampoco es útil reuniones de 200 personas :).
  • Introducí cambios que mejoren el equipo, el proyecto va a mejorar por el solo hecho de que el equipo esté más contento.
  • No te centres en las herramientas, centrate en las personas.
Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s