Hoy traigo a los fogones un plato de comida por encargo, y me he liado a escribir tanto que lo voy a dividir en dos partes. Empecemos.

De un tiempo a esta parte me llegan preguntas pidiendo que aconseje formas de empezar en “Agile”, así que me he animado a escribir esta entrada de iniciación con el ánimo de ayudar.

Empezando de cero

Si tuviera que empezar desde cero, empezaría por recalcar que ágil (o Agile que es la palabra de moda), es un adjetivo, y conviene repasar su definición, ya que la primera confusión suele ser pensar que ágil significa ir rápido.

A lo largo de este tiempo he escuchado a gente desinformada imaginar de qué se trata, recopilo algunas de las impresiones que he recogido:

• Es un movimiento de gente que dice que no hay que hacer documentación.
• Se trata de que no haya jefes de proyecto.
• Se trata de una especie de revolución de los desarrolladores que aboga por eliminar la gestión.
• Se trata de aprender a convivir con cambios en los requisitos constantes y continuados. Cuanto más nos cambien los requisitos los de negocio al día, más ágiles somos.
• Es una metodología que marca cómo debemos trabajar.

¿Consistirá ser ágil en algo de esto?

Intentemos definirlo

Estoy seguro de que si estáis aquí ya habréis buscado alguna definición como la de Wikipedia, así que para no aburrir, prefiero contar algo que me parece casi igual de importante, y que está basado en mi experiencia.

Son unos puntos para la reflexión que espero que puedan servir para evitar desviarse del camino:

• Recordemos que como adjetivo, no se trata de hacer Agile o de hacer Scrum, sino de ser más ágiles.
• Usar notas adhesivas no nos vuelve más ágiles.
• Usar Jira, Trello, TFS, Skype, Slack o lo que sea no nos hace más ágiles. ¿Centrar la discusión en las herramientas nos hace avanzar?
• Ser ágil no trata de hacer un curso para tener un título y unas bonitas cartas de Planning Poker.
• Si la única diferencia es que el jefe de proyecto ahora se llama Scrum Master no estás siendo más ágil.
• Es importante cuidarse de pensar en el agilismo como una religión, no es ni algo misterioso ni algo de lo que tengas que convencer a los demás.
• En la linea de lo anterior, no es algo que sólo ven unos pocos y que los demás no son capaces de ver.

Y sobre todo y ante todo: No se trata de gente que vaya diciendo qué es ágil y qué no lo es, ¡así que no me hagáis caso!.

Trabajando con personas

Seguro que os habéis percatado de algo que resulta curioso: parece más sencillo definir lo que no es ágil, ¿verdad?

Creo que se debe a que la clave de todo esto es la experimentación, porque por mucho que cualquiera intente transmitirlo explicándolo, el verdadero aprendizaje vendrá de la práctica.

Y os puedo asegurar que el camino es largo, porque se trata de aprender a trabajar entre personas.

Somos individuos complejos, repletos de sentimientos, emociones, motivaciones, etc. así que se dan casos en los que elegimos una metodología ágil, se cumplen todas y cada una de las prácticas propuestas, y aun así no se consigue sacar ningún rendimiento, ¡incluso puede llegar a ser contraproducente!

Sin embargo es un camino apasionante, porque las prácticas son sencillas de poner en marcha aunque sean difíciles de dominar, y al fin y al cabo se trata de adherirse a unos valores y principios, e intentar acercarse a ellos.

Ni más ni menos.

Recursos básicos:

Hay dos recursos que considero fundamentales para iniciarse en el desarrollo ágilde de software, por un lado el manifiesto ágil y por otro la guía de Scrum, esta última porque en la actualidad es el framework de referencia.

El Manifiesto Ágil.

Aconsejo visitar la web del manifiesto, leer y comprender los valores a los que compromete, y pasar un rato estudiando lo que quieren decir los doce principios.

Merece la pena descubrir su historia y quiénes son los autores originales (seguro que conoces a más de uno) para comprender que no es una “vendida de moto” más del mundo de la gestión, sino que emerge de una necesidad.

¿Te has dado cuenta ya de cuánto tiempo ha pasado desde entonces?

Por último, si durante el camino de todo este cambio te sientes perdido, te recomiendo volver a estos principios.

El año pasado fui a un Meetup de Madriagil para repasarlos y compartirlos, intentando ver si han quedado obsoletos, etc.

Es un ejercicio que merece la pena hacer de tanto en tanto.

El inicio de todo esto está ahí. ¿Estás dispuesto a dar el paso? ¿Vas a firmarlo?

Scrum

Scrum es un framework que sigue los valores ágiles, y uno de los errores típicos del principiante es pensar que son lo mismo, sobre todo porque en el desarrollo de software es el más comúnmente usado.

Para que lo entendamos, podríamos decir que es una de las implementaciones de estos valores, una propuesta o una guía para intentar ponerlos en práctica.

¿Entonces es la mejor metodología?

Pues no tiene por qué, lo mejor es ir conociendo qué más hay para decidir qué es lo que más nos conviene, reflexionando sobre sus limitaciones, pero es un buen comienzo por ser el más extendido.

¿Y cómo aprendo Scrum?

Lo mejor es usar el recurso gratuito más infrautilizado: la Guía de Scrum.

Lo mismo has llegado hasta aquí y ya habías oído hablar de Scrum, pero no conocías la guía. Sinceramente merece la pena echarle un vistazo para contrastar lo que sabemos, seguro que encuentras cosas que creías que formaban parte del framework y en realidad no lo son y viceversa.

Basta de teoría, ¿Por dónde empiezo?

Bueno, pues parece que en cuanto a teoría tampoco es que haya que hacer un master, no hace falta invertir dinero, ni hay técnicas enrevesadas, ni ciencias que se nos escapen, pero llega la hora de la verdad, ¿por dónde empiezo?

Pues si te estás planteando esto desde un nivel ejecutivo de la empresa, mi consejo sería que contaras con expertos, que los hay, y muy buenos, para ayudaros a comenzar en la empresa este proceso de cambio.

Ellos os ayudarán mucho más de lo que puedo hacer yo.

Si tengo que recomendar a alguno recomendaría a la gente de Thinking With You, AgileCapibara o Agilar .

Ojala sea ese el caso que te ha traído hasta aquí, pero estoy seguro de que no es el más habitual.

Si hago un ejercicio mental sólo disponible para unas pocas personas de mente preclara, imagino lo siguiente:

Eres un desarrollador que se siente frustrado porque cree que las cosas se pueden hacer mejor, pero no sabes muy bien cómo.

Yo quería una vida fácil pero parece que he seleccionado el modo experto. - Saber popular.

Sin el apoyo de la organización resulta mucho más difícil, pero no imposible cambiar cosas.

En cualquier caso reserva energía, porque descubrirás que la gente no cambia porque tu quieras, sino que deberás cambiarte a tí mismo.

Hace poco escribí sobre técnticas de guerrilla para el agente del cambio, contando algunas de las técnicas que me van funcionando.

Parar, la clave de todo

Si hay una práctica sobre la que gira todo esto, si tenemos que elegir sólo una, ésta sería parar para reflexionar.

En Scrum está establecido como una de sus ceremonias, llamadas retrospectivas.

No se trata más que de parar de vez en cuando (si lo establecemos en tiempos fijos mejor, para no encontrar escusas para no hacerlo), ver dónde podemos mejorar, y a partir de ahí probar nuevas cosas.

Hakan Forss lo resume con una imagen bastante conocida que por derechos no puedo reproducir aquí.

Lo puedes encontrar también como el Ciclo de Deming, o con la palabra japonesa Kaizen.

Hacer buenas retrospectivas es todo un arte, hay muchos recursos al respecto, existen cursos y libros enteros.

Por ejemplo Luis Gonçalves está ofreciendo actualmente en Oikosofy un curso/programa gratuito sobre retrospectivas ágiles.

Algo a priori sencillo pero que puede ser la clave para empezar a cambiarlo todo.

Continuará

Y hasta aquí la primera parte, prometo volver dentro de nada con la segunda parte del artículo, donde haremos un repaso a las diferentes áreas en las que podemos mejorar y os contaré muchos más recursos útiles.

¡No vemos pronto!