Tenía que dedicarle un post al tema, porque, no falla, cada vez que tengo que tratar temas Ágiles con organizaciones grandes, u organizaciones que trabajan para las grandes… sale esto de cómo hacer una transformación Ágil teniendo equipos (o empresas incluso), separados, unos dedicados al front y otros al back.
Normalmente, este tema suele salir cuando hablo de que las historias de usuario son, entre otros, «end to end», es decir, que cuando se termine de implementar la historia esta se habrá convertido en un incremento funcional del producto, que queda en pre o producción por parte de un único equipo. El equipo termina él solo la historia, por eso es multifuncional, porque el equipo Ágil es… multifuncional.
No Software: No Agile, No Scrum
If you are not producing working, running, tested usable software in every single Sprint or iteration, you are not [yet] ‘doing’ Agile, you are not [yet] ‘doing’ Scrum.https://t.co/s3ztpJvFkO— Ron Jeffries (@RonJeffries) September 5, 2019
Por si acaso, el anterior Tweet es de uno de los firmantes del Manifiesto Ágil
Tener equipos de front y back separados es… tener silos
Lo adornemos como queramos (o te lo cuente tu consultor todo lo bonito que tu quieras oírlo), dos equipos separados, teniendo que depender uno de otro para terminar una historia de usuario (pero una historia de usuario… historia de usuario, no una cosa rara a la que vosotros le llamáis historia de usuario), dependiendo uno de otro para poder dejarla en pre o producción, pudiendo ser usada funcionalmente, es tener… silos.
Y lo mismo ocurriría, sin ser el tema de hoy, si en vez de hablar de equipos front y back, habláramos del equipo de Testing o de uno de Operaciones.
Y los silos en el mundo Ágil no molan porque conllevan desperdicio: coordinación, comunicación, uno frena a otro, lo que uno creía que había terminado luego el otro descubre que no y se lo debe decir al primero en forma de incidencia, etc. Y se tarda más de lo necesario en terminar las cosas…
Silos (formato diapositiva retro, mía, sí, de hace unos 9 años)
Equipo Multifuncional (formato diapositiva retro, mía, sí, de hace unos 9 años)
Y este desperdicio es «de libro», antiguo como el que más, y ya hemos hablado de él: los tiempos de espera innecesarios para terminar algo crean el trabajo superfluo (trabajo innecesario).
Terminando…
Una cosa curiosa (o no tanto) sobre este tema, es la cantidad de gente que gente que vende a empresas grandes extrañas adaptaciones y justificaciones de cómo llegar a ser Ágil con silos
He escrito sobre la multifuncionalidad no sé ni cuantas veces, en el libro de «Peopleware y Equipos Ágiles», en post como este del 2015, o este del 2014, y otros tantos, te he dejado muchos vídeos (como el de abajo), incluso te dejo alguna referencia externa interesante a añadir sobre este tema y lo triste-curioso de esto es que, estando en 2019, la multifuncionalidad, como tantos otros, especialmente en empresas grandes… poco ha cambiado en el mundo real.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Estimado Javier:
Me parece que en estos casos es en los que comenzar a utilizar el concepto de DevOps como movimiento cultural de colaboración en una empresa puede hacer la diferencia.
Creo que una comunicación abierta entre los miembros del equipo multidisciplinario , respeto, confianza, incentivo y responsabilidad suman no solo al incremento funcional del producto sino también del equipo.
Es remar en dulce de leche con dos cotonetes, pero me parece que es el camino y no solo debería aplicar a las áreas de proyectos, sino que tendría que ser una cultura a aplicar en toda la organización.
Mil gracias por el post!!
Hola Javier !!!
Mi apreciación en la circunstancia que describes es que, mientras el paradigma subyacente en las organizaciones sea el viejo «waterfall o los proyectos» toda iniciativa orientada a «volvernos ágiles» estará teñida y frenada (como en el caso del dulce de leche del post anterior) por lo que es la zona de confort de lo que ya dio resultado en el pasado.
Es semejante a la teoría geocéntrica que guió el pensamiento y la acción en la antigüedad, hasta que fue reemplazado por la teoría heliocéntrica y abrió nuevas posibilidades.
Agile debe constituir un paradigma, que condicione la acción y que la acción defina los resultados.
Mientras permanezcamos dentro de un paradigma perimido, la gama de lo que pensemos y hagamos estará en ese nivel.
Saludos.