¿Cómo podemos aplicar todas estas ideas en nuestro día a día? ¿Para qué proyectos o equipos tiene sentido hacerlo?

En este artículo queremos dar respuesta a estas preguntas a través de diferentes ideas clave de implementación. Manos a la obra:

1. Equipos de entre 4 y 8 personas

Si el equipo está integrado por más personas y no tenemos experiencia en Agile, la operativa puede ser compleja de coordinar. A más personas, más potenciales dudas e inercias que todos arrastramos de antiguos esquemas de colaboración.

Si somos tres personas o menos, probablemente destinemos más tiempo a aprender las nuevas metodologías que a sacar un provecho real. Vale más esperar a una oportunidad donde nos sea útil de verdad aplicar estas técnicas.

2. Proyectos colaborativos: tareas interrelacionadas e interdependientes

¿Qué significa esto? Que los proyectos donde las metodologías Agile pueden aportar más valor son aquellos en los que el progreso del trabajo de algunos miembros del equipo depende del trabajo que hayan hecho o estén haciendo otros miembros.

Si el proyecto lo pueden conducir de manera autónoma cada uno de los profesionales del equipo, y el resto de las personas no necesitan saber en qué están trabajando los compañeros o cómo lo están haciendo en todo el proceso, entonces las metodologías Agile no tienen sentido.

En cambio, sí que es útil cuando el proyecto necesita poner en común los avances de cada persona para desarrollar nuevas soluciones y llegar a un objetivo común. Si el progreso de unos puede influir en el desarrollo de las tareas de otros, los valores Agile pueden ayudar mucho a mejorar esta coordinación y hacerla más eficiente.

3. Personas abiertas al cambio y generosas

Los valores Agile, como la colaboración, la transparencia, la eficiencia y la no-jerarquía, pueden chocar con las formas tradicionales de funcionar dentro de una empresa. Hay que dejar de lado los títulos y estatus de poder, puesto que en un proyecto Agile no hay un responsable general. Hay una alta auto responsabilidad y una clara división y especialización de roles, sin que ninguno tenga el control absoluto:

• Product Owner: Es el miembro del equipo que habla con el cliente final, ya sea interno o externo. Es quien marca la razón de ser del proyecto: qué necesita el cliente, cuál es su problema y definirlo detalladamente.
• Scrum Master: Coordina las reuniones en equipo y la implementación de la metodología Agile. Asegura que todo el mundo participe y que todas las ideas se manifiesten en el debate, que se respeten los compromisos y espacios definidos, que se resuelvan los bloqueos que van apareciendo en el proyecto y que nadie interfiera en las responsabilidades de los otros. Normalmente es la figura del HR Business Partner, conocedora de las habilidades y potencialidades de los miembros del equipo.
• Equipo de desarrollo: Son los ejecutores del proyecto y los que deciden cuál debe ser la vía para satisfacer las necesidades del cliente expuestas por el Product Owner. Quienes debaten, consensúan e implementan soluciones: los líderes reales del proyecto.

4. Haz una prueba con un proyecto concreto

Antes de implementar las metodologías Agile en todo un departamento de la empresa sin tenerlo claro, puede ser idóneo probarlo con un proyecto en concreto. Sin impactar todas las dinámicas de golpe. Puede ser un proyecto donde estén involucradas varias áreas de la empresa, o un equipo multidisciplinario, por ejemplo, para configurar una propuesta de colaboración innovadora para un cliente donde hagan falta las ideas y energía de diferentes áreas de la empresa (equipo técnico o de producto, marketing, compras, ventas, IT…).

5. No quieras correr: explica bien el cómo y el por qué de las metodologías Agile

Es fundamental el papel de acompañamiento del Scrum Master para evitar volver a las antiguas formas de organización y reducir una herramienta de valor para el equipo a un pequeño teatro. Entre otras cosas, debemos asegurarnos de que:

• Se respeten los roles. Que los antiguos “jefes” no impongan su manera de hacer al equipo de desarrollo.
• El panel de control (la pizarra Scrum) sea de utilidad para el equipo y para compartir información. Que no se convierta en una nevera de post-its que nadie lee, sino que la configuración de filas, columnas e información que se muestra aporte valor para avanzar en los objetivos comunes. De lo contrario, es mejor no tenerla.
• Se respete la operatividad de las reuniones: que no se conviertan en charlas interminables donde no se llega a ninguna decisión. La planificación de la primera reunión del proyecto (Sprint Planning) debe acabar con compromisos objetivos basados en las problemáticas detalladas del cliente. Las reuniones diarias (Daily Stand-ups) deben ser de 15 minutos y de pie, donde todo el mundo traslade el trabajo hecho, el pendiente y los obstáculos a resolver. Al final del proyecto, se debe comprobar la entrega de valor al cliente y validar que las metodologías Agile ayudan y no entorpecen el equipo. Si no es así, no es Agile.

En definitiva, las metodologías Agile son buenas en la medida en que aportan valor a los equipos a la hora de coordinarse. Hay que saber cuál es el momento y proyecto oportuno para aplicar estas técnicas, y hacerlo de forma valiente para que no acabe siendo un obstáculo, sino una solución.