La pregunta más importante sobre la escalabilidad ágil

Escuchamos de casi todas las grandes empresas con las que trabajamos: "Necesitamos un framework de escalabilidad ágil." Cuando 50 o más desarrolladores necesitan colaborar, usar un framework de escalabilidad es realmente beneficioso. Pero una pregunta queda sin respuesta. Una suposición tácita e incuestionada flota como un espectro sobre cualquier enfoque de escalabilidad. Pero antes de hacer esta pregunta, echemos un vistazo a las razones por las que esta pregunta necesita ser respondida.

Desarrollar un producto complejo

Los sistemas complejos son complejos – aunque solo sea por definición. Una suposición común es que Dividir y Conquistar (D+C) es un buen enfoque para resolver problemas complejos: dividimos un problema grande en muchos pequeños, los distribuimos y reensamblamos las soluciones. Esto también suena prometedor.

Un framework de escalabilidad puede entonces usarse para maximizar la efectividad de D+C.

Comencemos con las preguntas periféricas para acercarnos a la pregunta central:

¿Cómo definir el problema?

Cuando comienzas a desarrollar un producto grande, primero tienes una necesidad – y quieres construir un producto que satisfaga esa necesidad. La naturaleza del desarrollo de productos es que la solución basada en la necesidad aún no existe.

¿Está el problema siquiera descrito correctamente? ¿Ya está suficientemente claro hacia dónde va el esfuerzo? ¿El dominio del desafío ya está tan claro que D+C puede aplicarse de manera sensata?

¿Cuál es el verdadero problema?

Cuando organizas el desarrollo de productos, simplemente asumes que la necesidad está claramente definida y el resto es "solo trabajo".

Pero ¿qué pasa si incluso la pregunta sobre la base de la cual se hizo la planificación ya estaba equivocada? ¿Qué pasa si el plan falla y persigues la respuesta equivocada? ¿Ayuda que más personas trabajen en las cosas equivocadas?

¿Dónde está el verdadero problema?

La suposición básica de la escalabilidad ágil: "El problema principal es más trabajo del que pocas personas pueden hacer." Como también se describe en otro artículo, ¡el problema principal con mucho trabajo es que mucho trabajo causa mucho trabajo! Esto se trata de trabajo que no agrega valor, como coordinación, cambio de tareas, reuniones y similares.

¿Alguna vez has pensado en qué tan grande es la proporción de trabajo que agrega valor al producto en comparación con la proporción de trabajo que no agrega valor a los procesos en tu organización? ¿Cuánto tiempo necesitan tus desarrolladores para la coordinación debido a la complejidad de tus estructuras? ¿Tu enfoque está en entregar productos o seguir procesos? ¿Qué pasa con la sobrecarga cuando extiendes tus procesos? ¿Qué pasa con el tiempo de desarrollo que agrega valor?

¿Es el problema realmente tan grande?

Con la escalabilidad ágil, simplemente asumes que necesitas muchas personas para construir el producto que estás planificando. La siguiente pregunta es entonces cómo organizar a estas personas de la mejor manera.

¿Sabías que Google fue desarrollado por dos personas en sus primeros años? ¿Y Facebook por una?

¿Tu producto es realmente tan grande que eclipsa a Google y Facebook? ¿Realmente vas a ganar miles de millones? ¿Tu comprensión y enfoque son realmente óptimos?

¿Realmente mucho ayuda mucho?

El libro "The Mythical Man-Month", escrito hace unos 40 años por Frederick P. Brooks, hace mucho tiempo refutó la idea de que "cuantas más personas trabajan en un producto, más rápido se termina". Pero aún hoy, muchas empresas siguen creyendo que la "escalabilidad ágil" es la solución del "mítico mes-hombre". Como se mencionó antes, grandes productos fueron desarrollados por solo unas pocas personas – y más personas crean más trabajo, ¡pero no más valor!

¿No podrías encontrar una mejor solución con menos desarrolladores y menos trabajo? ¿Realmente sería más lento si participaran menos personas?

Después de tantas preguntas llegamos a la pregunta central crítica:

¿Es realmente necesaria la "escalabilidad ágil"?

Considera los siguientes puntos:

• ¿Tienen los desarrolladores el 100% del mejor conocimiento para proporcionar una solución?

• ¿Tienen la tecnología 100% mejor posible para resolver problemas?

• ¿Están los desarrolladores 100% enfocados en entregar el máximo valor?

• ¿Es cada actividad 100% generadora de valor?

• ¿Es el trabajo realizado 100% efectivo?

Si se añaden más personas, estos porcentajes tienden a no subir. Disminuyen.

Cuando estos porcentajes se suman, los resultados a menudo son alarmantes. Quizás tienes diez personas que solo pueden usar el 20% de su potencial – de modo que tres personas que pueden usar el 80% de su potencial ¡progresarían más rápido!
Si 100 desarrolladores están limitados al 5% de su potencial, ¡quizás un solo equipo sería más efectivo que todos ellos!

¿Has explorado todas las posibilidades para hacer más con menos?

Solo si todas estas preguntas ya han sido respondidas con "Sí" – entonces la respuesta a la pregunta central también es "Sí". Antes de eso, ¡escalarás tus problemas – y no la solución de tus problemas!