Pese a nuestros mejores esfuerzos, necesitamos saber lo que vamos a programar antes de escribir el código. Y sin importar cuánto nos guste escribir pruebas antes de escribir el código, en realidad no podemos ejecutar las pruebas hasta que hayamos escrito algo de código. Ágil solapa el relevamiento de requerimientos y la implementación, de manera que la programación puede empezar con requerimientos mínimos o apenas esbozados, pero incluso aquí hay una secuencia.
Y sin embargo, cuando se trata de arreglar un proceso de desarrollo malo, empezar con los requerimientos puede empeorar la situación. Aunque parezca poco intuitivo, la primera prioridad tiene que ser lograr que el desarrollo sea más efectivo, y luego enfocar la atención en el proceso de requerimientos.
Demanda en exceso
Uno de los problemas más frecuentes en las organizaciones es un flujo de requerimientos de negocio que los grupos de desarrollo no pueden satisfacer, simplemente porque son demasiados pedidos. El resultado es el equivalente a intentar servir un chop de cerveza dentro de un vaso: se desborda.
El trabajo también se desborda y no se realiza; los gerentes gastan su tiempo discutiendo sobre lo que debería hacerse, y porqué hay cosas que no se hicieron. Los desarrolladores toman atajos de manera que el trabajo que se realiza no satisface la necesidad. La calidad se sacrifica en el nombre de entregar algo en fecha - a veces, cualquier cosa.
Parte de esto ocurre por la forma en la que se piden los requerimientos y características. Es muy facil pedir una nueva característica. Una petición puede ser tan facil como enviar un e-mail al líder de desarrollo, en cuyo caso el costo de realizar la petición es mínima.
Los equipos de desarrollo a menudo responden incrementando el precio de los pedidos. Antes de que se pueda considerar cualquier trabajo, debe estar formalmente documentado y firmado. Al incrementar el costo se reduce el flujo de pedidos, pero también se vuelve más dificil el poder hacer una vuelta atrás de pedidos que ya fueron hechos.
Sin importar la forma en la que se realice el pedido, es normal que satisfacer esta petición tome más tiempo, energia y recursos que hacerla. En consecuencia, hay un desbalance entre la oferta y la demanda. La demanda es casi ilimitada, el costo de hacer pedidos es bajo y este costo no se incrementa al hacer más pedidos. Sin embargo, la oferta está estríctamente limitada y es muy costosa. Incrementar la oferta va a incrementar los costos porque se necesita más coordinación (tanto de gestión como técnica).
Es fácil ver como se incrementa la ldemanda. Algunos pedidos son simples "ideas simpáticas" que se escapan dentro del proceso de requerimientos. Otras son el resultado del bajo rendimiento de equipos de IT anteriores, agotados por fallos previos a clientes internos.
Los proyectos conocidos en general se entregan tarde y sin toda la funcionalidad prometida al cliente; los clientes hacen más y más pedidos esperando que al menos obtendrán algo de lo que querían. En respuesta a esto, los equipos de desarrollo responden alargando las planificaciones, demanando más recursos e implementando criterios de ingreso de proyectos ("algunos proyectos si, otros no").
Al mismo tiempo de hacer más pedidos, los clientes piden más detalles - planes de proyecto y tiempos - e incluso se meten dentro del proceso de desarollo para monitorear qué hace el equipo y cómo trabaja. Es frecuente que ambas partes se oculten detras de planes y de una ilusión de control.
No es sorpresa entonces que Mary y Tom Poppendieck nos digan: "sólo el 20% de las características y funciones de un software a medida se utilizan regularmente". Cualquier organización que en serio quiera seguir una agenda Ágil o Lean necesita regular los requerimientos entrantes para asegurarse que sólo se implementen las características útiles.
Por suerte, esta forma de pensar se ajusta con lo que piensan la mayoría de los gerentes. A muchos gerentes se los capacita en la importancia de hacer las cosas correctas por sobre hacerlas bien. Es un buen consejo, pero en el caso de equipos de IT problemáticos, hacer esto puede empeorar a la situación.
La trampa de los requerimientos
Investigaciones de Bain & Company muestran que un increíble 76% de todas las organizaciones de IT no son efectivas en lo que hacen ni están alineadas con las necesidades del negocio. Podemos pensar en estos dos criterios como en "hacer las cosas bien" (efectividad) y "hacer las cosas correctas" (alineación).
Usando estos dos criterios - efectividad y alineación - se identifican cuatro tipos de organización - a los consultores les encantan las matrices 2x2!
El primer grupo se llama "zona de mantenimiento": estas empresas son menos efectivas y menos alineadas. Estas empresas tienen un gasto en IT promedio y como consecuencia de un IT pobre, las ventas cayeron alrededor de un 2% anualmente durante 3 años.
No sorprende que las empresas de Alto Rendimiento, que son más efectivas y alineadas al negocio - hacen las cosas correctas y las hacen bien - constituyen sólo el 7% de las empresas, y demuestran tener un gasto en IT 6% por debajo del promedio, e incrementos en sus ventas por el 35% anual.
Asumiendo que una organización esté en la "zona de mantenimiento" - después de todo, el 76% de las companias están aquí - tienen que decidir en qué enfocarse primero: en ser más efectivos o más alineados, hacer las cosas correctas o hacerlas bien.
Tradicionalmente, Ágil mejora la efectividad de los equipos de desarrollo. Aunque Ágil no ignora a los requerimientos, el empuje en la mayoría de los procesos Ágiles es para mejorar la efectividad. Mejorar la efectividad le permitirá a un equipo moverse desde la "zona de mantenimiento" al siguiente cuadrante (llamado "bien aceitado"). Al ser más efectivas, las empresas hacen las cosas bien, pero no necesariamente hacen las cosas correctas.
Sin embargo, los resultados de las empresas de IT "bien aceitadas" son impresionantes. El 8% de las empresas en esta categoría demuestran tener gastos en IT 15% menores al promedio, mientras que sus ventas se incrementan un 11% anual.
Estos números nos muestran que ser un equipo de desarrollo efectivo es un buen lugar para estar, y una gran mejora para muchos. Por el sólo hecho de ser efectivos ahorramos una importante cantidad de dinero. Para muchas empresas lograr esta posición será suficiente para mantenerse competitivas.
¿Pero qué pasa con los requerimientos? Llegar a "bien aceitado" no soluciona la necesidad de producir lo que necesita el negocio. ¿Que pasaría si, en cambio, siguieramos el instinto de gerentes? ¿Qué pasaría si mejoramos la alineación y nos enfocamos en hacer las cosas correctas antes de hacerlas bien? ¿Vamos a tener un resultado incluso mejor?
La respuesta es NO. Este grupo de empresas está en el cuadrante de "trampa de alineación". Aunque están más alineadas al negocio, su efectividad es pobre. Estas empresas tienen altos gastos en IT (hasta un 13% por sobre el promedio), y más preocupante es que sus ventas caen más rápido, un 14% por año más que las empresas en "zona de mantenimiento". Resulta ser que hacer las cosas correctas de manera pobre es el peor lugar para estar. Este 11% de empresas está en la peor situación.
Y la cosa empeora: una vez que se cae en la "trampa de alineación" es más dificil moverse para lograr un Alto Rendimiento (el cuadrante de alineado y efectivo) que para quienes están "bien aceitados".
¿Por qué resulta que hacer bien las cosas incorrectas es mucho mejor que hacer mal las cosas correctas? La explicación la encontramos en nuestro viejo amigo La Cascada.
Las organizaciones que intentan hacer las cosas correctas se enfocan naturalmente en los requerimientos. Esto las lleva a tomar el enfoque de "primero los requerimientos". Aquí comienza la cascada, y como el 80% de los requerimientos suelen ser innecesarios, estas organizaciónes crean la demanada que empuja los costos hacia arriba.
Explicando Ágil
Este modelo explica porqué Ágil tiene un éxito tan importante en la actualidad. Ágil tiene sus raíces en lo que hacen los desarrolladores. Esto resulta más evidente si miramos a uno de los primeros métodos Ágiles en ganar popularidad: Extreme Programming (XP).
XP explica cómo un cliente genera requerimientos, pero XP se preocupa más por lo que hacen los desarrolladores: TDD, refactor, diseño simple, etc. Al hacer énfasis en el proceso de desarrollo, XP mejora la efectividad.
Como resultado, XP y otros métodos Ágiles son muy buenos en hacer que los equipos de desarrollo sean más efectivos, y se muevan desde la "zona de mantenimiento" hacia el cuadrante de "bien aceitado". Este movimiento en sí es sumamente beneficioso para la organización, y puede ser suficiente para justificar el cambio hacia Ágil.
Este cambio es posible porque muchas de las prácticas y procesos fomentados por los primeros métodos Ágiles pueden ser adoptados por los desarrolladores sin mucha necesidad de involucrar a la gerencia. Los programadores pueden empezar a escribir pruebas unitarias primero, pueden empezar a hacer refactors, pueden configurar un servidor de integración continua. Se necesita muy poca involucración de la gerencia para aprobar estos cambios.
En consecuencia, los primeros éxitos de Ágil fueron desde abajo hacia arriba. Los desarrolladores lo hicieron. En contraste, hay muy poco que puedan hacer los gerentes para imponer estas actividades: sólo los desarrolladores saben cuándo es apropiado hacer un refactor, forzar TDD puede llevar a pruebas sin sentido que barras verdes todo el tiempo, y ¿cómo va a saber un gerente cuándo un diseño es simple y cuando no?.
Tampoco es posible que una organización haga una transición a Scrum a través de un decreto. Ningún gerente puede forzar a que un equipo se auto-gestione sólo por ordenarlo.
Entonces, los equipos pueden adoptar prácticas Ágiles y mejorar su rendimiento, e incluso moverse hacia el cuadrante de "bien aceitado". Pero solucionar el flujo de requerimientos necesita del apoyo y la autoridad de la gerencia.
Resolución
Existe una paradoja para la organización que está haciendo la transición hacia un desarrollo Ágil de requerimientos. Para ser realmente Ágiles, y aprendiendo de Lean, se deben ordenar los requerimientos de manera que se desarrollen aquellos con el mayor valor, aquellos que realmente vayan a usarse. Y sin embargo, intentar solucionar este tema al principio de una transición hacia Ágil puede hacer que las cosas empeoren.
Resolver este problema es un tema de secuencia. Al inicio de cualquier transición se necesita hacer foco en las prácticas y equipos de desarrollo, y el proceso de requerimientos se debe dejar "como está".
Esto significa que hay que adoptar prácticas de desarrollo, estructuras de rutinas y organización que permitan que los requerimientos flujan sin problemas a través del sistema. Entran los requerimientos, sale software funcionando. El primer beneficio de mejorar la efectividad del desarrollo es construir confianza.
Una vez que se creó confianza siguen más beneficios, como que los clientes pueden discutir los requerimientos ya no en términos de lo que quieren, sino en prioridades relativas. Las conversaciones puede moverse desde "¿Cuándo va a estar listo?" y "¿Por qué no está funcionando?" hacia asuntos que importen, sobre lo que realmente se necesita y cuándo se lo necesita.
Desde aquí se hace posible arreglar el problema de la alineación, y moverse desde "bien aceitado" hacia un "Alto rendimiento". Como dice Bain: "Al revés de la creencia popular, el camino hacia un crecimiento de IT yace primero en lograr una alta efectividad, y sólo luego se debe asegurar que los proyectos de IT están bien alineados con el negocio".
¿Qué sigue?
El mensaje es claro: el primer paso en la adopción Ágil es arreglar la maquinaria de entregas. Mejorar la efectividad del equipo de desarrollo.
A medida que mejora la efectividad, se puede pasar el foco del cómo al qué. Los cambios que se necesitan aquí son a mucho más largo plazo.
A la fecha, los métodos Ágiles tienen poco que decir sobre los requerimientos y la alineación al negocio. La mayoría de los métodos Ágiles actuales hacen foco en el desarrollo y en las prácticas de gestión de proyectos. A medida que más empresas adopten Ágil - y pasen a estar "bien aceitadas" - seguramente veremos un nuevo enfoque hacia el relevamiento de requerimientos y alineación con el negocio.