En el año 2001 en Snowbird, Utah, 17 personas -principalmente norteamericanas- se juntaron para descansar, relajarse y charlar sobre aspectos en común que tenían las diferentes formas de trabajo de las que eran representantes. Entre ellas, Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming. No tenían claro qué podía salir de todo aquello, pero sí entendían que algo tenía que cambiar en el mundo del software al que pertenecían, debido al dominio que había en la industria de procesos rígidos y guiados por una extensiva documentación. De ahí surgió el Agile Manifesto, una serie decuatro valores y 12 principios que esas 17 personas acordaron que eran necesarios seguir para provocar un cambio de paradigma en el desarrollo de software.
Quizás hoy en día, el uso de los términos agile o ágil han tomado un ámbito más amplio que el del propio software, relacionándose con contextos donde predomina la colaboración, la entrega continua de versiones incrementales de un producto, la colaboración y contacto con los clientes, y la relevancia en la integración y pruebas del trabajo realizado. Sin embargo, y aunque esto sea lo que aparentemente debería suceder, en muchos de los casos se puede quedar en una mera etiqueta que oculte aquello que realmente está sucediendo. Por ello, vamos a intentar plantear qué han supuesto estos valores y principios.
El primer valor que determinaron era que Personas e Interacciones deberían primar sobre Procesos y Herramientas. Podéis encontrar organizaciones donde se aplique Scrum, Kanban, Lean Startup, Extreme Programming,… sin embargo, la aplicación de estas formas de trabajo no implica que se esté velando porque las personas puedan relacionarse de la mejor manera posible. Se puede aplicar Scrum en entornos altamente jerarquizados, donde el control de la información supone la diferencia entre un jefe y un subordinado, entornos donde el número de departamentos es tan grande que no puedes llegar a retenerlos en la cabeza y, sí, se puede aplicar Scrum. Scrum no deja de ser un proceso simple con unos roles y unos artefactos. Quizás lo que sea más difícil que ocurra es que aplicando Scrum u otra forma de trabajo la organización se plantee que hay que trabajar conjuntamente para entregar al cliente que nos da dinero, que más allá de desarrollar software o hacer una campaña de marketing o un contrato de legal, está cuál es la mejor manera de relacionarme con mis compañeros para entregar lo antes posible al cliente.
Scrum no deja de ser un proceso simple con unos roles y unos artefactos.
El segundo, que el software funcionando debería primar sobre la documentación extensiva. Quizás retiraría la palabra software para darle un ámbito mayor y pondría Producto, de tal forma que podamos entender que en Agile trabajamos desde un esfuerzo conjunto para entregar lo antes posible al cliente productos que funcionen. Esfuerzo conjunto indica que toda persona relacionada con la entrega al cliente debería entender qué debe hacer para que eso sea posible, tanto desde su función individual como la de integrar su trabajo con sus compañeros. El concepto documentación está referido al desarrollo de material en muchos casos interno y que obstaculicen la obtención de feedback del cliente, es decir, es más importante lanzar una versión de nuestro producto y darnos cuenta en base a estadísticas de interacción o entrevistas cara a cara qué botones pincha más, o que páginas visita más, que generar un manual de usuario donde esperamos que haya una serie de interacciones que puede ser no ocurran nunca.
El tercer valor plantea la necesidad de responder al cambio sobre seguir el plan. Volvería a cambiar la palabra responder por adaptar, donde lo que buscamos no es dar respuesta, sino incorporar comportamientos a situaciones para que no vuelvan a suceder. No queremos solucionar una incidencia una y otra vez, queremos que no vuelva a ocurrir jamás, y esta es la principal diferencia entre métricas que nos ayudan a adaptarnos y otras que nos ayudan a responder. Buscamos poder entender que el plan simplemente es un estado de nuestra planificación y que nuestra planificación debe nutrirse de la información que consideremos oportuna para poder orientar mejor nuestras acciones y generar mejores negocios.
El último valor pero no menos importante trata de que Colaborar con el Cliente predomina sobre la negociación contractual, y esto pasa desde adaptar los contratos para beneficio de todas las partes, a generar contratos de temporalidad adaptada a la entrega del producto, pero sobre todo a tener un diálogo abierto y continuo con las necesidades del cliente. Estar en contacto directo con cómo interacciona con nuestro producto será fundamental para recoger feedback real sobre la generación de negocio.
Desde estos valores surgieron los 12 principios que estos 17 gurús de las diferentes formas de trabajo Agile establecieron. Me suele ocurrir que normalmente poca gente se los ha leído y que muchos de ellos no nos acordamos habitualmente de todo el contenido de los mismos. Para mí hay cinco aspectos fundamentales que los resumen, intentaré ser esquemático:
- Acortar ciclos de feedback con cliente.
- Primer paso: completar alguna pequeña interacción de cliente, aunque no pueda ser lanzada como un producto y validarla con él. Segundo paso: lo mismo teniendo en cuenta el primer paso.
- Hablar todo lo que podamos cara a cara entre las personas.
- Incidencias y defectos 0.
- No somos adivinos, no sé cuándo voy a entregar mi producto, pero sí soy consciente de dónde estoy y lo que me falta para ello y trabajaré para entregar lo antes posible. Esto no significa no tener una fecha de entrega, significa poder adaptarla con información continua de dónde estamos como equipo respecto a nuestros clientes.
Por algo se empieza, pero si he de quedarme entre aplicar Scrum, Kanban, Lean Startup, Extreme Programming, DSDM, Prince2, Adaptive Software Development… o notar si algún valor o principio agile está en una organización y qué puedo hacer para que emerja, siempre me quedaré con esto último. Metodologías, frameworks, … y personas diciendo que los usan hay muchas, pero conozco pocas personas que de verdad cambien la forma en la que se relacionan con ellos mismos, con sus clientes y con sus compañeros. Quizás cada vez conozcas más, aún así, en mi opinión, pocas.
Por Florentino Romero Haro @worldintino
