Somos agile o utilizamos la famosa palabra

Las necesidades del marcado cambian constantemente, surgen nuevas tecnologías y tendencias, y la importancia de llegar al mercado en el momento adecuado se vuelve crítico para tener el retorno de inversión que vamos buscando. Incluso en algunos casos se habla de que ese «time-to-market» es la nueva divisa en la que deberíamos movernos. La forma de trabajar está cambiando radicalmente. Ya no podemos planificar a largo plazo y ceñirnos únicamente a ese plan, sin mirar alrededor.

Pero en algunos otros casos se confunde agile con falta de estrategia. La estrategia o la visión no debe faltar en ningún caso, sino estaremos navegando a la deriva, y con ello llevaremos al traste todos los esfuerzos de los equipos con los que trabajemos y tendrá un impacto negativo muy visible en la empresa.

Para empezar, y asegurarnos que estamos hablando de lo mismo. ¿En que consiste esto de Agile? Como he comentado en el primer párrafo estamos viviendo una época de cambios constantes, lo que era válido hace unos meses está muy anticuado hoy, y necesitamos incorporar algún factor adicional en nuestras decisiones. Por este motivo, en el mundo del desarrollo del software surgieron las metodologías agile. Estas metodologías descomponen un problema grande en pequeños trozos y van desarrollándolo en pequeños entregables. Por lo tanto, las dos principales características que tienen estas metodologías son:

• Flexible y dinámico: al partir el gran problema a resolver en pequeños trozos que son desarrollados de forma independiente, es fácil incorporar o cambiar nuevos requerimientos. Esto es fundamental en el ambiente en el que nos movemos, donde la incertidumbre y los cambios constantes guían nuestro trabajo diario. Debemos tener una estrategia general, pero los detalles pueden variar durante el transcurso del tiempo.
• Llegar al mercado de forma más rápida: Al igual que los cambios pueden producirse de forma mucho más rápida y nuestros requerimientos pueden cambiar de un día para otro, debemos ser capaces de llegar al mercado con nuestro producto (con la calidad esperada) lo antes posible. Por lo tanto no estamos hablando de reducir la calidad, sino la frecuencia con la que sacamos nuevas funcionalidades, mejoras, arreglamos fallos o introducimos soluciones a nuevos requerimientos. Reducir el alcance global en pequeños trozos nos permitirá acelarar el avance y desarrollo del proyecto, dando visibilidad sobre cada pieza con más agilidad.

Aunque estas metodologías nacieron en el mundo del desarrollo del software, cada vez se están adaptando más al negocio, ya que en el fondo estamos hablando de como resolver  misma problemática, y tener un impacto positivo mayor y más rápido en el negocio.

Trocear el problema en pequeños componentes, que podamos resolver de forma unitaria, nos dará la flexibilidad de buscamos a la hora de cambiar, introducir o eliminar requerimientos, y si nos proporcionará la velocidad que necesitamos para salir al mercado (o tener listo ese componente) lo antes posible sin tener que esperar a tener la solución completa totalmente lista. Por supuesto que siempre hay dependencias y nos vamos a encontrar dificultades por el camino. La comunicación entre equipos es un factor decisivo. Los equipos de trabajo deben ser multifuncionales, para poder abordar el problema desde todos los puntos de vista, pero lo suficientemente pequeños para mantener ese dinamismo, agilidad y velocidad que necesitamos. De nada servirá intentar aplicar esta metodología a un equipo de grandes dimensiones, ya que seguiremos teniendo los mismo limitantes que encontrábamos antes (y por lo tanto el resultado será el mismo)

Y no olvidemos que el objetivo principal en desarrollar y entregar trabajo en menor tiempo. No tiene porque ser la solución entera al problema a resolver, pero si los pequeños componentes en los que los hemos subdividido. Ya sea de forma interna o externa seremos capaces de recibir feedback y ajustar lo necesario en el trabajo a desarrollar. Como he repetido en numerosas ocasiones en este blog, tenemos que probar la idea que tenemos en la cabeza (y en la estamos trabajando) lo antes posible.

Muchas veces nos autolimitamos ya que queremos salir al mercado con la solución más completa posible. Muchas veces esto es contraproducente. Por un lado, cuando antes estemos presentes, antes empezaremos ese dialogo con los clientes. Y ellos nos ayudarán a construir el resto del producto. Se ha visto en ciertas ocasiones que salir al mercado con un producto completamente terminado no ha sido la razón del éxito. Bien el cliente no estaba preparado para ello, o no era que o que buscaba. Mejor co-crear y evolucionar de forma iterativa. Pero co-crear no quiere decirse sentarse y esperar instrucciones, sino testar soluciones, ver que puede funcionar y recoger feedback constante del cliente para ver que necesita (todo ello siempre basado en datos)

Como podrás ver se trata de un proceso muy iterativo. Lanzaremos esos componente (lo que se conoce como una release), siempre que haya pasado ciertos criterios de calidad, ya que queremos seguir manteniendo la misma o mayor calidad, pero evolucionaremos esas características en el tiempo para hacerlas mas completas y perfectas. Ir poco a poco nos ayudará a entender mejor en que dirección movernos.

Agile es por lo tanto, un conjunto de metodologías que nos ayuda a entender mejor al cliente, con la que podemos desarrollar proyectos de forma más rápida y que debe entenderse como iterativo. Los equipos deben ser multifuncionales y pequeños para permitir esa agilidad. La eliminación de burocracia es uno de los puntos que debemos conseguir. En teoría el tiempo de eliminación de creación de documentación puede ser utilizado en el desarrollo como tal de la solución y dotarle de más calidad. Aunque esto no siempre es posible, por lo que por lo menos debe limitarse la burocracia al mínimo indispensable para mantenerlo bajo control. Sino estamos dispuestos a hacer estos cambios, dejemos de utilizar la palabra agile, y no queramos obtener resultados diferentes y más rápidos.