Trabajando agile con equipos no agile

Asumamos que ya sabes qué es el manifiesto agile. Consideremos que aplicas la mayoría de los valores, principios y prácticas de “extreme programming”. ¿Cómo puedes trabajar con otros equipos que no son agile?

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación de contratos
• Responder ante el cambio sobre seguir un plan

Estás usando bucles de feedback cortos, donde las cosas cambian constantemente. Puedes sentir que el equipo está vivo y cada uno es esencial.

Abrazas el cambio hasta el punto de que disfrutas saliendo de tu zona de confort cuando es necesario. Buscando crear valor para tu equipo y sus dinámicas, y siempre considerando el crecimiento personal.

Pero claro, asumamos todo eso -y todo lo demás que pueda haber olvidado respecto a la “agilidad”, ¿cómo podrías trabajar con un equipo externo que no es agile? ¿Cómo podría tu “equipo perfectamente agile” trabajar con otro grupo de personas que no tiene nada que ver con software? Por ejemplo, un médico.

Un médico no tiene tiempo para aprender sobre tus “valores y principios agile para desarrollo de software”. Un médico no tiene tiempo para aprender sobre “extreme programming”. De manera similar, no tienen tiempo para aprender sobre testing, diseño, arquitectura y buenas prácticas relacionadas con el software en general.

¿Cómo podrías crear un puente entre ese médico y tu equipo de software?

¿Cómo podrías trabajar agile con ese médico?

Si necesitas trabajar con ese médico es porque él/ella debería ser un experto de dominio. Sugiero que uno o dos miembros de tu equipo se reúnan con ese experto durante 30/60 min, para que puedan hablar y compartir sus impresiones. Y luego repetir esto tanto como sea posible para acortar el bucle de feedback. Por ejemplo, una vez a la semana.

Recopilar esos requisitos e impresiones de los expertos y luego dirigir el diseño de tu software de acuerdo con eso es Domain-Driven Design. Puedes encontrar mucha documentación sobre DDD en libros (como Domain-Driven Design Distilled) o en muchos blogs en Internet.

Sin embargo, el aspecto crítico aquí no es qué requisitos o impresiones se están resolviendo sino cómo. ¿Cómo podrías trabajar agile con ese médico?

Agile es sobre feedback rápido. Es sobre comunicación efectiva y reducir desperdicio mientras se apunta a la simplicidad.

Al aplicar verdaderamente estos cinco valores, ya estás actuando de forma agile

• Comunicación
• Feedback
• Simplicidad
• Coraje
• Respeto

Estos objetivos abstractos aplican a cualquier profesión - e incluso a la vida, no solo al software.

La comunicación continua ayuda a acortar el bucle de feedback, lo que simplifica las tareas. Siempre con el coraje de abordar la verdad y respeto mutuo.

Las prácticas son las cosas que haces

• Sentarse Juntos
• Pair Programming
• Test First
• Diseño Incremental
• y muchas más

Y a pesar de tener un nombre técnico, podrían aplicar a cualquier profesión:

• Sentarse Juntos & Pair Programming: pensar y hacer con otros compañeros
• Test First: verifica tus suposiciones primero, luego resuelve el problema
• Diseño Incremental: lo que sea que hagas, hazlo mejor incrementalmente

Los principios guían y motivan las prácticas hacia los valores

• Beneficio Mutuo
• Diversidad
• Fracaso
• Oportunidad
• Pasos Pequeños
• Calidad
• y muchos más

El beneficio mutuo es el más importante porque se trata de encontrar prácticas que nos beneficien ahora, a nosotros después, y también al cliente.

Otros principios incluyen la diversidad de ideas. No tengas miedo del fracaso. Mira todo lo que haces como una oportunidad de aprendizaje. Evita pasos gigantes porque tienen mayor riesgo de fallar. Apunta a un sistema de alta calidad porque son más predecibles y más fáciles de cambiar.

La pregunta permanece: ¿eres agile?

Creo verdaderamente que un equipo agile es el que puede lidiar con el cambio a nivel de equipo. Por lo tanto, primero debes dominar agile dentro de tu equipo, y luego puedes colaborar con otros equipos de “manera agile”.

Una vez que hayas interiorizado estos puntos anteriores, puedes aplicarlos mientras trabajas con cualquier persona de cualquier equipo.

Aunque estas ideas aisladas son buenas, son aún más poderosas cuando se combinan. Crean una atmósfera de curiosidad y aprendizaje activo. Incluso podría despertar alguna pasión por tu profesión que construye un aura de cohesión de equipo, y así sin más, el equipo respira por sí mismo.

Todos se preocupan y asumen plena responsabilidad de mantener al equipo saludable construyendo confianza. No hay miedo a conflictos saludables. Se sienten empoderados y responsables de sus compromisos. El equipo celebra sus resultados y aprende de sus errores; ya no hay necesidad de máscaras.

Es entonces cuando la magia empieza a suceder, y de repente puedes trabajar agile con cualquier equipo, especialmente el tuyo.

Posts relacionados

• Actualiza tu equipo para ser más extreme. ¿Cómo puedes ayudar a tus compañeros a abrazar el cambio?
• Entendiendo a las personas. Malentendidos, comunicación efectiva y autorreflexión

Lecturas relacionadas

• Clean Agile por Robert C. Martin
• Extreme Programming Explained por Kent Beck
• The Five Dysfunctions of a Team por Patrick M. Lencioni