El asunto con el escalamiento es que se nos está convirtiendo en una cuestión de cuál método usar y no en lo que verdaderamente importa a las Organizaciones: ¿por qué escalar? Debemos ir a la causa raíz, el problema detrás del problema, es quizás una de las pocas vías razonables que tenemos para encontrar una razón de peso para escalar Ágil y tal vez un buen camino a seguir.
Los marcos de trabajo o los métodos de escalamiento proporcionan herramientas que ayudan en el proceso, pero me parece que apenas si nos permiten lograr que los equipos realicen correctamente el trabajo y que lo hagan de manera integrada. Pero hacer correctamente el trabajo correcto es otra cosa.
Cuando empezamos la transformación a o la adopción de Ágil, lo hacemos provistos con el Manifiesto Ágil y quizás Scrum o Kanban, acompañados de algunas otras prácticas y el pensamiento Lean. Tenemos la férrea esperanza de que el área de TI no necesite nada más allá de algunas otras herramientas Ágiles que hoy ya podemos brindar como “paquetes” (BDD, Refactoring, User Story Map, entre otras).
Luego nos damos cuenta que, contrario a lo que sucedía con el enfoque tradicional, el Ágil es un pensamiento que debe tener un lugar en cada uno de los asientos de la empresa y en cada lugar que habitan sus miembros. Entonces, cuando queremos salir fuera de la oficina de TI, hacia el resto de la Organización, nos olvidamos del Manifiesto y nos aprovisionamos con todo tipo de artilugios ‘agilísticos’ como si se tratara de la cruzada definitiva, la última cruzada de los agilistas o algo similar.
Pensamos más en el número de equipos y de personas a escalar que en el Valor y en el número de productos o servicios que debemos desarrollar.
No todas las corporaciones necesitan escalar Ágil. Algunas solo necesitan Ágil para entregar software con Valor de manera temprana y frecuente. No se trata de que tan Ágil soy comparado con mis vecinos, más bien de lo que se trata es de si voy correctamente en el camino Ágil correcto y de lo que debo hacer para mantenerme allí.
En definitiva, lo que tenemos que responder, mientras seguimos encontrando formas mejores de hacer las cosas, tanto por nuestra cuenta como ayudando a otros, es si nuestra Organización o la que estamos acompañando en su camino Ágil ve el tiempo de respuesta como un diferenciador crítico para sus consumidores finales o ante sus competidores.
Pero aun más importante es si queremos escalar la forma cómo pensamos acerca de las personas y sus interacciones o solo la forma de desarrollo de nuevos productos y servicios. ¿Queremos escalar el nivel de motivación y felicidad de nuestros compañeros de trabajo y colegas o solo su productividad y eficiencia? Y si se trata de ambas cosas, ¿lo estamos haciendo? Más aun, ¿lo estamos haciendo de una manera correcta?
Otros porqués incluyen:
- ¿Qué tan innovador queremos que sea el portafolio de la Organización?
- ¿Qué tanta incertidumbre hay en nuestros esfuerzos de desarrollo y, por extensión, en nuestro futuro?
- ¿Queremos innovar o simplemente realizar el mejor mantenimiento posible a lo que hacemos y proporcionamos?
- La estocástica también juega un papel importante. ¿Qué tan aleatoria es la demanda de nuestra Organización?
Finalmente, ¿estamos planeando o ejecutando ya una metempsicosis organizacional, en el sentido de transformación, a la que podamos sumar la adopción de Ágil a gran escala? ¿O simplemente queremos vender o implantar una marca más por asuntos de moda que por aspectos fundamentados en la ingeniería y en las prácticas de la industria?
¿No será que estamos cayendo una vez más en el uso de un gran número de métodos o marcos de trabajo y sus variantes, con diferencias poco entendidas e incrementados artificialmente y que además carecen de evaluación y validación experimental creíble? Eso ya nos sucedió, de allá venimos, de metodologías y prácticas inmaduras que obstaculizaban gravemente la ingeniería de software, en particular, y el desarrollo y entrega de productos y servicios con Valor, en general.
Otro asunto, riesgoso y de mayor impacto para la Organización, es tratar de escalar sin haber terminado de construir los cimientos o cuando todavía hay disfunciones Ágiles en el nivel más básico. En ese caso, lo único que lograremos escalar serán precisamente los problemas, no las soluciones. Pero este será tema de otro artículo.
Escalemos la entrega de Valor, no solo el método o marco de trabajo que queremos usar.
Si tengo un producto muy grande, donde van a intervenir 30 equipos de desarrollo, y todos trabajando sobre un mismo backlog... ¿solo con esa premisa ya no basta para escalar la agilidad?.
ResponderBorrarJL, muchas gracias por tu participación en el foro, nos da la oportunidad de continuar la conversación.
BorrarRespuesta corta: ¡es posible!
Respuesta extendida:
El número de equipos no es la única variable a tener en cuenta en estos casos. Es posible pensar en escalar solo con este factor, sí. Pero también es posible no pensar en ello.
30 equipos suponen un escenario mucho más complejo que 5 o 7 equipos y uno muchísimo más caótico que un solo equipo, sí.
Quizás (y este es un quizás en letra grande y subrayado) sea suficiente con reforzar (también en negrita y subrayado) las prácticas actuales y concentrar una gran parte del esfuerzo en el manejo de dependencias, en la integración del trabajo y en la creación de incrementos integrados de Valor como lo propone el pensamiento Ágil y que podemos implementar con marcos de trabajo como Scrum. A lo que me refiero es a que quizás no sea necesario imponer a la Forma de Trabajo actual procesos, prácticas o modelos de “carga ancha o larga”.
Incluso podemos pensar en “desescalar” el problema, como lo he recomendado muchas veces. Hacer productos con 200 (30 equipos de 7 personas, por ejemplo) o más personas no es que sea algo nuevo de la Ingeniería de Software. El problema era el enfoque que usábamos entonces y que ahora hemos sorteado muy bien con el modelo iterativo e incremental y el trabajo colaborativo que propone el pensamiento Ágil.
Trataré de ir un poco más allá. Hay que mirar otras variables: alcance y complejidad del producto. Y no me refiero solo al alcance en materia de requisitos, sino al espectro de escenarios que la solución cubrirá una vez entre en funcionamiento. ¿Qué tan heterogénea es esta solución? Si solo es un producto “grande” (una enorme pila de funcionalidades o de componentes “tradicionales”) entonces no es necesario escalar. Está claro, no es lo mismo construir un ERP (de hecho SAP en Alemania es una de las instalaciones más grandes de Scrum en el mundo que ya en 2014 contaba con miles de equipos Scrum a su haber) que el sistema que llevará personas a Marte en las próximas décadas.
La cantidad y el nivel de transversalidad (jerarquía) de interesados (léase ‘stakeholders’) en el producto también es algo a tener en cuenta. Si hablamos de un producto que va a pagar un área (una persona) de la compañía y cuyo desarrollo y puesta en marcha estará bajo la tutela de un pequeño grupo de personas (aunque sea un producto para miles o millones de personas), entonces no será necesario pensar en multiplicar los esfuerzos que significa escalar la Agilidad con que lo vamos a construir. Si por el contrario, muchas personas de muchas áreas, estarán “pendientes” o influirán en las decisiones a lo largo del ciclo de vida, eso es otro cantar.
¡Y podría seguir!
Lo realmente bonito de Ágil es que nos permite experimentar, proponer hipótesis y probarlas en escenarios seguros.
Si además de esto, estamos entregando Valor (al Negocio) cada 30 días o menos, estamos haciendo el trabajo de manera colaborativa, estamos reflexionando a intervalos regulares (inspeccionando y adaptando a partir de los resultados que arrojen las pruebas a las hipótesis lanzadas) y estamos mejorando continuamente, podemos estar tranquilos, ¡el resto es opcional!
¡Enhorabuena por tu participación!