Hace poco estaba hablando con un cliente potencial que estaba preocupado por la velocidad de sus equipos de Scrum. Habían adoptado un enfoque ágil hacia 9 meses, y habia esperado lograr una velocidad de entrega mucho mayor a la alcanzada.
Y ahora querían incrementar la cantidad de equipos de Scrum en el proyecto para incrementar la velocidad y entregar más rápido. En mi experiencia, aumentar la cantidad de personas en un proyecto (en especial uno que tiene problemas) nunca logra el efecto deseado de ir más rápido. El consejo que le di al cliente fue buscar formas de hacer que sus equipos y procesos existentes sean más efectivos, en vez de incrementar la cantidad de personas en el proyecto.
Y esto me llevó a pensar en distintos motivos por los cuales los proyectos ágiles avanzan lento. Identifiqué 4 factores comunes: dos relacionados con las personas y los procesos, y dos relacionados con temas técnicos.
Problema 1: las personas equivocadas
En Ágil es muy importante tener a las personas adecuadas. De hecho, esto es cierto para cualquier proyecto o proceso, pero en ágil es aún más importante. Si participan las personas adecuadas, el proceso ágil va a funcionar. Si participan las personas equivocadas, tendremos problemas.
Las personas que no queremos en un proyecto ágil son aquellas que no tienen la disciplina suficente para seguir prácticas de ingeniería fuertes, y aquellas que quieran construir un frameworks complejos y que llevan adelante proyectos de "investigación persnoal" en el código. Si queremos ir rápido entonces resulta esencial tener una base de código limpia, simple y bien ordenada, que esté sustentada en un grupo de pruebas de calidad. Los miembros del equipo que no apoyen esta visión van a frenar a todo el equipo.
Para encarrilar la situación, quiten a aquellos desarrolladores que no tengan un disciplina estricta, y aquellos que hacen las cosas más complicadas. Traigan desarrolladores ágiles con experiencia para trabajar en parejas con el resto del equipo, dándoles la responsabilidad de garantizar que las prácticas de calidad se apliquen.
Problema 2: Poner primero al proceso
Otro error común de las empresas al comenzar con proyectos ágiles es asumir que los procesos por si mismos van a hacer que funcionen más rápido. Siendo desilusionarlos, pero no es cierto. Lo que hace que los equipos ágiles seaan más rápido es que crean canales abiertos de comunicación, con equipos auto-organizados, colaborativos y con autoridad para tomar decisiones.
Si una organización no puede crear un excelente entorno para la comunicación, entonces ningún proceso ágil los ayudará. Los equipos ágiles van más rápido porque eliminan la documentación innecesaria y los pasos en cascada. Sin embargo, esta transferencia de información sigue ocurriendo y ocurre usando canales de comunicación más cercanos y colaborativos.
Lamentablemente, muchas organizaciones crean equipos ágiles y les dan un proceso a seguir, pero insisten en decirles cómo organizarse, qué herramientas y técnicas usar, cómo trabajar y exactamente qué hacer. Eso no es ágil, simplemente es otra forma de organizar un equipo tradicional. Si querés ir más rapido con ágil, entonces el equipo necesita control total sobre cómo trabaja y qué hace.
Para encarrilar la situación, relajá el proceso. Trabajá en incrementar la comunicación. Dale a los equipos ágiles la oportunidad de decidir cómo se van a organizar y trabajar. Dales el control, e irán más rápido. Ágil no es un proceso, sino que es un marco para que las personas terminen su trabajo.
Problema 3: Usar las tecnologías equivocadas
Muchos proyectos ágiles están en problemas porque usan las tecnologías equivocadas. Cuando esto ocurre, usualmente es porque el enfoque tecnológico fue impuesto al equipo por un "arquitecto aislado" o algún manager que fue convencido por un vendedor. En otros casos es porque los equipos se ven forzados a usar un "estándar corporativo" de tecnologías.
En muchos casos el equipo identifica a la tecnología problemática en las retrospectivas. Sin embargo, lo más probable es que le digan que eso es algo que no pueden cambiar, y que tienen que seguir usándolo.
Nuevamente, hay que darle la autoridad a los equipos para que tomen las decisiones tecnológicas. También es parte de ser ágil el permitir revertir decisiones tecnológicas si se prueba que retrasa las entregas.
Problema 4: Hacer una arquitectura muy compleja
Muchos sistemas de software se diseñan, o se vuelven, demasiado complejos. En un ambiente ágil esto garantizará que todo se vuelva más lento. El software tiene que mantenerse lo más simple posible, para lograr que sea facil mejorarlo continuamente.
Si la arquitectura del sistema se tan demasiado compleja que retrasa el desarrollo, entonces es buen momento para revisarla y simplificarla. Se pueden eliminar capas innecesarias, reducir las interfaces y realizar refactors para simplificar todo. Una vez que esté esto realizado, se tiene que trabajar en equipo para evitar que el proyecto vuelva a ponerse complejo en el futuro.
Sólo si empleamos a las personas correctos, con autoridad de decisión y comunicadas, puede un equipo tener la habilidad de ir más rápido y ser realmente ágil. Sólo si tomamos las decisiones tecnológicas correctas, mantenemos el código simple, y revertimos las malas decisiones, podremos tener la habilidad de realizar entregas verdaderamente ágiles.
