Luego de recibir un curso, charla o seminario de Agile o Scrum se genera un gran entusiasmo al conocer una nueva forma de crear software, un conjunto de nuevos principios y sobretodo al descubrir los muchos beneficios que la agilidad brinda sobre el enfoque de desarrollo tradicional. La energía crece al saber que Agile o Scrum no son las metodologías o frameworks de moda, sino más bien un movimiento que está empujando a la industria del software y a otras hacia nuevas direcciones en las que se garantiza productos de calidad y clientes deleitados (algunas estadísticas #mce_temp_url#).

Como resultado del estusiasmo, al siguiente día la oficina luce paredes llenas de post-its, varios StoryBoards y compañeros de pie ensayando su primer Stand-Up meeting. Toda esta buena energía es positiva, sin embargo debe ser correctamente canalizada. En el proceso de adopción de Agile muchas organizaciones comienzan velozmente al aplicar las prácticas sin tomar mucha atención en la interiorización de los valores Agile. Generalmente todos desean aplicar Scrum pero no se tiene un inicio claro del qué vamos a hacer, porqué o para quién.

En mi experiencia al comenzar a plasmar los conceptos de la agilidad, he resumido unos pocos pasos que están dando buenos resultados en el proceso de adopción en la empresa en la que trabajo y que deseo compartir:

1. Full Empowerment: contar con el respaldo total por parte de la organización (o instancias superiores) acerca del proceso de adopción de una práctica ágil como Scrum para el desarrollo; la organización debe estar convencida de los beneficios que brindará sobre la manera de crear software. Agile implica muchos cambios a nivel cultural y de procesos que deben ser auspiciados por la empresa. Este respaldo es importante ya que brindará autonomía al equipo y le dará espacios transparentes para la toma de decisiones. La difusión del inicio del proceso como un programa piloto es parte de este punto. Si Usted es un emprededor ágil debe comenzar a «vender» y generar confianza en los directivos de su organización.

2. Invitación a participar a las personas que lo deseen: Identificar e invitar a las personas que posean los perfiles apropiados, talentos y habilidades pero por sobretodo, estén con muchas ganas y entusiasmo de comenzar con Agile. Que su forma de pensar y de actuar sea de cierta forma coherente con los valores y principios de la agilidad y que estén deseosos de aprender y mejorar. A mi forma de pensar, pesan más las ganas, la capacidad de aprender, desaprender y reaprender por sobre el badaje técnico que se pueda tener.

 3. Identidad: Cuando propuse este punto como parte del inicio de un equipo, muchos me preguntaron…para qué?. El sentido de identidad va más allá de un nombre para el equipo, consiste en brindar un sentido de pertenencia, unión y colaboración entre las personas que conforman el equipo. Identidad la entiendo como la definición de un nombre, valores, principios y acuerdos que constituyen la cultura del equipo y rigen su comportamiento. La siguiente pregunta fue: pero…no son los mismos valores y principios del Agile Manifesto??. Mi respuesta fue: hagamos de este equipo nuestro equipo y que represente lo que somos y lo que hacemos. La definición de la identidad es la primera reunión del nuevo equipo -nada formal-, donde todos aportan efusivamente y se llega a los primeros acuerdos. Cada nuevo miembro del equipo debe estar de acuerdo y comprometerse con lo acordado.

4. Lenguaje común: consiste en el manejo homogéneo de conceptos, términos y prácticas -tanto técnicas, tecnológicas, procedimentales y de agilidad- de los miembros del equipo; no necesariamente con gran nivel de profundidad o un manejo experto de cada tema; pero si una visión y comprensión de los conceptos que usará el equipo. Durante mi experiencia en este punto, se organizaron varias charlas informarles entre los miembros del equipo (no más de 40 minutos entre contenido y preguntas), en donde todos propusimos temas en los cuales se tenía ciertas dudas, deficiencias o simplemente temas que se querían conocer; además de los que todos considerábamos importantes antes de iniciar. Fue un proceso de aprendizaje bastante satisfactorio, ya que los que más conocían acerca de algo compartían su experiencia con los demás miembros. Se hicieron breves Coding-Dojos y talleres altamente participativos. En muchas literaturas se denomina a este punto como Iteración 0, sin embargo pienso que más que una evaluación de nuestra habilidad con herramientas y tecnologías, la formación de un Lenguaje común es un elemento que involucra otros aspectos y que no necesariamente están dentro del contexto de adquirir o conocer nuestro Velocity.

5. Envisionamiento del Producto: Okay, es aquí donde comenzamos a vivir más intesamente la agilidad. Básicamente la definición del qué vamos a hacer, el porqué y para quién se realiza en este punto. Qué es lo que vamos a lograr como equipo. Es la definición del norte acerca del producto que se desea construir. Como todos sabemos, en Scrum es el Product Owner quién acerca la idea al DevTeam a través del Product Backlog. Es vital contar un PO con las características adecuadas y el conocimiento que dirigirá el esfuerzo del equipo de desarrollo. El PO motiva al equipo. Su Product Backlog lo reta constantemente y le inyecta dinamismo. Si no se cuenta con un PO lo más recomendable para mí es emprender un proyecto al interior de la misma empresa, alguna solución que agregue valor en donde nuestros compañeros más conocedores del negocio al cual se quiere ayudar, nos entregue su enfoque de producto sin ser necesariamente un PO, podemos involucrarlos y juntos con el equipo emprender un proceso de discovering y crear una visión de producto compartida, en la cual poco a poco se vayan abordando prácticas como el Visual story Mapping con la participación y el conocimiento de todos.

6. Requisitos Operacionales: consiste en la definición de aspectos importantes para el desempeño diario del equipo:

• Common workspace: Importantísimo. un ambiente de trabajo que fomente la colaboración, comunicación y comodidad del equipo, facilite las Daily Meettings y otras reuniones, se puedan ubicar StoryBoards, etc.
• PCs, networking, ambientes de desarrollo, pruebas de usuario o de review, servidor de integración continua, herramientas de colaboración y comunicación.
• DevOps: el primer acercamiento del equipo de infraestructura hacia la agilidad. El concepto de DevOps es acercar al equipo de desarrollo con el de infraestructura-operaciones de la compañía. Estos dos mundos que siempre han estado separados, ahora trabajan junto con el DevTeam para realizar una exitosa entrega continua. Las tareas de Configuration Management, Versionamiento y otras son manejadas en este contexto. Por lo general en equipos o empresas pequeñas estas tareas son manejadas por el mismo DevTeam, sin embargo cuando existen muchos proyectos o se requiere colocar entregables en ambientes de producción de ciertos clientes estas operaciones conjuntas son necesarias (hablaré más de DevOps en un siguiente post más adelante).

7. Y…creo que estamos listos para emprezar!!

Estos pasos no son una guía formal o rígida (tanto en el orden como en la forma de abordar cada punto). Crear un equipo ágil depende mucho del contexto de la empresa, las personas y de los productos a construir; pero espero que en un sentido general estos pasos sirvan de utilidad para aquellos que desean comenzar firmente el camino hacia la agilidad y hacia un crecimiento personal y profesional. Me gustaría conocer sus comentarios y/o sugerencias al respecto. No olvidemos que Agile involucra un aprendizaje continuo.

Muchos saludos.