Todos hacemos agile… ¿o no?

Hace unos años en España, cuando nosotros montamos ASPgems, hacer proyectos de forma “agile” era una extravagancia, en el mejor de los casos. Sin embargo hoy no es extraño oír hablar a CTOS de grandes empresas de “scrum”, “sprints” y herramientas de gestión “ágiles”.

Nosotros no somos quienes para decir quién hace o no hace proyectos de forma ágil y, a pesar de que a priori parece que ágil no casa con cosas como especificaciones o documentación, lo cierto es que los límites de determinados conceptos, como estos últimos, son difusos y el debate sobre lo qué es, qué no es y lo que parece que es, puede acabar en matices y tecnicismos que pueden ser interesantes para pasar una tarde de debate, pero irrelevantes a la hora de elaborar un discurso sobre el valor diferencial que como empresa tenemos a la hora de hacer proyectos. En otras palabras: decir hoy que tu empresa hace desarrollo ágil no supone un valor diferencial suficiente y, además, empieza a resultar un concepto confuso o, incluso, vacío.

Nosotros creemos que el agilismo son “principios y ceremonias”, una cultura y una filosofía que atraviesa e impregna a una organización. Es por eso que nos gusta más hablar de “nuestra forma de hacer proyectos” que ha ido cambiando con los años, fruto de la experiencia que hemos adquirido.

 

Nuestra forma de hacer proyectos. 

Te dediques a hacer desarrollo de software o a gestionar proyectos de cualquier tipo, sabes que un proyecto siempre es único y complejo. Hacer un proyecto es tan fácil como caminar por el agua… lo único que necesitas es que el agua y las especificaciones estén congeladas.

Lo normal cuando ejecutamos un proyecto es que lo hagamos ciñéndonos a un plan, generemos un modelo, hagamos un presupuesto, definamos unas funcionalidades, un tiempo de ejecución, calculemos los riesgos, nos anticipemos a los problemas y preparemos alternativas.

La realidad es que esta forma de hacer proyectos no funciona, por varias razones:

  1. Lo cierto es que cuando piensas en un proyecto tienes una idea aproximada de lo que quieres o necesitas; sobre todo porque te falta información y si esperas a tenerla, seguramente llegues tarde al mercado. 
  2. El futuro cambia constantemente; el mundo al que llegará tu proyecto es diferente al mundo en el que lo concebiste. 
  3. Tus ideas cambian, porque estás recibiendo información constantemente de la que te impregnas y con la que puedes enriquecer tu proyecto. 
  4. La tecnología cambia en cuestión de semanas. La mejor solución hoy puede no serlo pasado mañana. Hay que tener en cuenta que cuando hablamos de tecnología el “largo plazo” son tres meses.

 

Nuestra aproximación a la hora de diseñar un proyecto es que elijas dos del trío tiempo, recursos y especificaciones; la idea es preguntarse ¿Cuánto se tarda en hacer este proyecto con los recursos que tengo?¿qué es lo mejor que puedo hacer con el tiempo que tengo y los recursos que puedo invertir? 

La cuestión es mucho más peliaguda de lo que puede parecer en principio, pues, como dice nuestro socio José Cabrera, se trata de un desafío adaptativo, para el que necesitamos principios diferentes a los que tradicionalmente estamos acostumbrados a manejar. Por si esto fuera poco, no sólo somos nosotros los que necesitamos abrazar principios nuevos y disruptivos, sino que el hecho de que creamos firmemente que la mejor forma de hacer un proyecto es co-crear con nuestros clientes implica que éstos últimos deben también “comprarlos”.

Nuestra fórmula 

En realidad, no es ningún secreto. Llevamos más de 10 años haciendo proyectos así y hay varias presentaciones colgadas en Slideshare que han ido evolucionando a lo largo de los años. Sin embargo, creemos que nuestros 10 principios merecen algo más de tiempo y de reflexión y una serie de artículos que desgranen qué somos y cómo eso vertebra todo lo que hacemos.

  1. Colaboración. Básica para el éxito del proyecto y la única forma de asegurar que todas las partes están involucradas, sabiendo que el éxito personal pasa necesariamente por el del grupo. Colaboración, porque todos nos equivocamos pero, habitualmente, no a la vez y porque de esta forma detectamos antes los errores y somos capaces de encontrar mejores soluciones. 
  2. “Menos es más”. Como principio aplicable a todo lo que hacemos; Tal y como estudió Barry Schwartz en el MIT, a partir de un número de opciones que elegir el nivel de satisfacción decae. Reducir las funcionalidades te ayudará a definir tu mínimo producto viable, abaratará el proyecto, reducirá el tiempo de ejecución y te ayudará a llegar a tiempo al mercado. Además reduce la posibilidad de errores y facilita la adopción por parte de los usuarios. El “menos es más” está tan metido en nuestra cultura que no sólo atañe al desarrollo. Toda idea que surge en la empresa sea desde marketing o en el área comercial debe empezar a implementarse desde este principio.
  3. El usuario manda. El cliente ya no “manda” sobre el diseño y el desarrollo. Es el usuario final del servicio quien decide qué funciona y qué no, quien nos dice qué cosas son importantes. Y quien muchas veces nos sugiere nuevos servicios y funcionalidades en los que no habíamos pensado. Esta es la esencia de la web 2.0. Seth Godin la resume de forma brillante: “Si el usuario final dice que algo está roto, es que está roto”.
  4. Buscamos el “mínimo producto viable. El core que recoja la esencia del proyecto. Somos máquinas de generar ideas y la complejidad muchas veces hace que un proyecto no salga adelante.  
  5. Diseñamos por unanimidad. No puede ser de otra manera si tratamos de hacer un trabajo colaborativo de verdad donde todas las personas estén involucradas al 100%. Todo el equipo ( cliente incluido) tiene que “comprar” la idea.  
  6. Darwinismo funcional. Analizamos las funcionalidades en clave de coste beneficio, de forma que el proyecto tienda a tener funcionalidades con gran beneficio y bajo coste y las mínimas posibles de gran coste y poco impacto. 
  7. La información es tiempo. Decidimos lo más tarde posible, porque tenemos más información que nos permite equilibrar el coste/error y nos ayuda a mantener el foco en cada momento. 
  8. No hacemos modelos, iteramos con la realidad. El tiempo es crítico, lo mismo que los recursos. Probamos un prototipo o lanzamos al mercado un MPV; Recogemos las opiniones de tus usuarios y medimos. Intentamos que los productos de nuestros clientes evolucionen con el mercado y con los usuarios. 
  9. Iteración. A través de sprins cortos en los que se implica al cliente y haciendo scrum una vez a la semana en la empresa y una vez al día en los equipos de proyecto.
  10. Agilidad. Intentamos aplicar los principios del manifiesto agil a todo lo que hacemos: personas e iteraciones sobre los procesos, proyectos en marcha sin mucha documentación de por medio, cocreación con el clientes en lugar de negociaciones y flexibilidad ante los cambios, sin ceñirnos a un plan preestablecido.
Estos son los 10 principios con los que abordamos los proyectos y creemos que están en la base de más del 98% de los proyectos que ejecutamos sean un éxito. Más adelante hablaremos de cómo aplicamos el resto de “ceremonias y principios” más allá del desarrollo de software.

Gracias por tu interés en ASPgems. Déjanos tus datos y nos pondremos en contacto contigo lo antes posible.