Luis Hernandez 23/12/2020

Para poder determinar esto primero debemos entender que son las metodologías agiles ya que he notado que el principal detonante de que estas no funcionen es que se implementa de forma errada, donde he conocido agile coach con poco criterio del tema argumentando que todo se debe seguir al pie de la letra según el marco de trabajo (Scrum siendo el más popular) con esta premisa se está fracasando desde el inicio el uso de la metodología.

Marco de trabajo flexible

Entender que agile no es seguir un marco de trabajo al pie de la letra es complicado para algunos, que están acostumbrados a seguir pasos religiosamente estructurados (Waterfall) y con esto caemos en más de lo mismo. La idea es entender las virtudes y defectos de tu equipo para lograr los objetivos de negocio de forma eficaz y a un ritmo incremental, el Scrum master como orientador debe conocer a su equipo y tratar que en cada iteración puedan entregar valor a través del software, no es solamente convocar las ceremonias de scrum y ver el burndown chart , aquí también fallan muchos "Scrum master", bajo mi perspectiva un Scrum master que no tenga el más mínimo conocimiento técnico realmente aporta poco y aquí seguramente muchos me cuestionarán pero analicemos lo siguiente "Desbloquear al equipo de dependencias externas es labor del Scrum Master" mi pregunta es ¿como desbloquearás una dependencia técnica con otro equipo si no tienes idea del porqué esa dependencia? en otro post hablaré más de esto pero volvamos a la pregunta inicial.

Entiende los problemas de tu organización

Para que Agile funcione en tu organización esta debe nacer con voceros que realmente entiendan agile, entiendan los problemas de la compañía y en base a estos buscar el camino correcto para agile, por ejemplo si en la empresa donde estas ahora los procesos son burocráticos, lentos y fuertemente estructurados, implementar agile al pie de la letra de un marco seleccionado tendrá un impacto negativo total, es un cambio cultural muy fuerte que puede generar discordia interna, lo más idóneo es empezar con pequeños proyectos y empezar por el negocio y sí, el negocio primero pero te preguntarás ¿Por qué? y es simple, los equipos deben integrarse con el negocio, la figura del Product Owner es fundamental ya que además de concientizar al mismo entendiende las capacidades de cada equipo para construir software, elimina esa línea en la que en waterfall cuando se define un proyecto, negocio define sus necesidades y estas pasan por un Project manager, analistas, proveedor, etc y cuando estamos a mitad del proyecto, faltaron requisitos o se requieren más y estos deben pasar por esta cadena nuevamente llamando al terrible "cambio de alcance" (si en tu organización son "agile" y escuchas cambios de alcance a cada rato pues no hay nada de agile allí) para evitar esto se crean equipos donde negocio y desarrollo están juntos y así las necesidades del negocio estarán con el equipo que las convierte en valor para el negocio.

Luego que logras que negocio trabaje junto al equipo de desarrollo, si el marco de trabajo es scrum necesitaras un scrum master y aquí hago énfasis que un equipo no logre sacar proyectos de forma ágil es responsabilidad del Scrum Master, este debe conocer a su equipo entender las dependencias externas, motivar al equipo a seguir mejorando y encontrar el marco de trabajo correcto que se adapte al equipo.

Por ejemplo en scrum debemos tener las dailys, refinamientos, planning, review y retrospective, tomemos como ejercicio para este post solo las dailys, digamos que al inicio las tienes todos los días con tu equipo y las mismas preguntas de siempre (que hice ayer, que hare hoy, si tengo algún bloqueo) si después de 3 meses ese equipo tiene las mismas dailys todos los días ese Scrum master ha fallado, ¿La razón?¿Qué valor le ha sacado a esa reunión de "15" minutos cada mañana? y si es que dura 15 minutos, he estado en equipos donde duran casi una hora, convirtiéndolas en reuniones de seguimiento del Product Owner para saber qué hiciste y que no (Waterfall=Burocracia) y este no es el objetivo de las dailys, de hecho en equipos maduros estas dailys las decide el equipo y se reúnen solo ellos para comentar algún bloqueo y generar una estrategia para solucionarlo. Como Scrum Master de un equipo nuevo, busca el valor de las dailys y que le pueden aportar al equipo, que no sea una reunión repetitiva de seguimiento, que puedan darle realmente al equipo la visión de las tareas y en que pueden ayudarse entre ellos para completarlas.

En Resumen

Que la metodología ágil funcione en tu organización depende de los facilitadores de la misma (Agile Coach, Scrums e inclusive Product Owners) y que la cultura de tu compañía sea capaz de adoptar estos cambios y para esto deben ver resultados, empieza por proyectos pequeños que sean agile y que este muestre los resultados en tiempo y coste, del alcance olvídate en agile pero esto lo explicare en otro post.