Cómo lograr ser agile

Cómo lograr ser agile

Llegado a este punto, espero haberte convencido de las bondades del agile y del bien que puede hacer a tu organización o proyecto.

Bueno, pues si estás decidido a que tu próximo proyecto software sea agile, ¿por dónde empezar? ¿qué debes tener en cuenta para iniciarte en esto del agilismo? ¿cómo saber si ya soy ágil o cuánto me queda para serlo?

En resumen, ¿cómo lograr ser agile?

A lo largo de este post veremos qué pasos seguir, desde cero, para que puedas lograr el calificativo de ágil. Vamos a ello.

Generar un cambio cultural

Lo primero que debes asumir es que trabajar de forma ágil supone principalmente un cambio cultural. Así de simple y así de complicado. Las técnicas, ceremonias, herramientas o métodos son secundarios ante esto.

Ya puedes tratar de aplicar rigurosamente un marco de trabajo ágil como Scrum, utilizar las herramientas orientadas a la agilidad más populares como Jira o Confluence, empapelar tu puesto de trabajo de postits…, que como tu organización no respete este paradigma al final estarás aplicando un agile puramente cosmético, simple postureo.

Y por desgracia, esto es algo muy muy habitual en las empresas españolas, sobre todo en esas que aparecen en el IBEX35…

Cambio de mentalidad
Primera acción: cambio de mentalidad!!!

Por tanto, el primer paso hacia la agilidad está en que tu empresa se comprometa a respetar el Manifiesto Agile y sus cuatro valores, con todo lo que ello implica. Repito los cuatro valores por si aún no te los grabaste a fuego:

  • Individuos e interacciones sobre procesos y herramientas.

  • Software funcionando sobre documentación extensiva.

  • Colaboración con el cliente sobre negociación contractual.

  • Respuesta ante el cambio sobre seguir un plan.

Te aseguro que, si realmente tu organización respeta el Manifiesto Agile, ya habrás recorrido gran parte del camino hacia la agilidad. Y te lo digo porque es el paso más complicado ya que implica un cambio cultural tal que en empresas de nuevo cuño puede ser relativamente fácil, pues no arrastran ningunos vicios previos, pero en empresas con solera no es nada sencillo semejante cambio de chip.

Elegir un método ágil

Vale, supongamos que todos aceptan las reglas del juego y se comprometen con los dictámenes del Manifiesto Agile. El segundo paso sería elegir algún método ágil o marco de trabajo que te permita llevar eso del agile a la práctica. Ya te he comentado en otros posts que considero Scrum como la referencia indiscutible.

De todas formas, te recomiendo que seas consciente de tus necesidades y no te metas en camisas de once varas innecesariamente: si vas a tomar los mandos de un equipo de resolución de incidencias a demanda, un simple panel kanban puede hacerte un apaño estupendo. No te compliques tontamente ni te dejes llevar por la moda.

Usa Scrum cuando realmente tenga sentido: si tu futuro proyecto software encaja con un modelo iterativo e incremental, Scrum te será tremendamente útil, así que adelante, apréndelo bien y practica. Sólo la práctica y la experiencia te permitirá verdaderamente sacar jugo a un método ágil. No esperes que, por leer la guía Scrum o algún que otro libro o incluso aprobar una certificación, podrás llevar exitosamente a la práctica un método ágil de un día para otro.

Además, deberás respetar el método agile que decidas utilizar. Y cuando digo respetarlo me refiero a no saltarte las reglas cuando te apetezca: o usas un marco agile o no lo uses, pero no te hagas trampas al solitario.

Por ejemplo, si usas Scrum, debes tener Product Owners con la suficiente potestad para decidir sin restricciones ni trabas sobre el contenido y prioridad del Backlog, equipos autogestionados y autoorganizados con suficiente autonomía como para trabajar sin injerencias externas, Scrum Masters que actúen como tales y no como jefes de proyecto encubiertos, etc. No te preocupes si no entiendes estos términos, ya te irán encajando las piezas cuando comencemos a profundizar en Scrum, pero sea como fuere no caigas en lo que algunos llaman Scrumbut, es decir, un sucedáneo de Scrum.

Cuenta con profesionales adecuados

Deberás contar con buenos profesionales agile que sepan realizar correctamente su rol dentro del marco de trabajo ágil elegido.

Por ejemplo, en Scrum procura contar con un Product Owner de verdad. Ya dedicaré un post a este rol imprescindible, pero por ahora decir que difícilmente podrás realizar un Scrum decente sin un Product Owner medianamente solvente. Por tanto, asegúrate que la persona que asume esta responsabilidad tenga claro su rol y cómo debe llevarlo a cabo.

Aunque no hay que caer en la titulitis, no estaría de más que fuese un Product Owner certificado, de esta forma te asegurarás de que por lo menos conoce el marco de trabajo y no le suena a chino cada cosa que le cuente el Scrum Master o el Equipo de Desarrollo.

Además, asegúrate de contar con un Equipo de Desarrollo adecuado. A la hora de montar este equipo es muy común reunir a un puñado de gente cada uno de una disciplina técnica y con nula capacidad de autogestión. No cometas ese error.

Procura que se trate de un grupo de personas con autonomía, no simplemente técnicos que ejecutan órdenes. Aquí la mentalidad vuelve a ser decisiva: deben tener un sentimiento de que la responsabilidad cae sobre todo el equipo y que ellos deben responder de los avances (o falta de avances) del proyecto. Mientras mantengan la mentalidad de yo-hice-lo-que-me-mandaron y la de ocultarse tras un jefe de proyecto que dé la cara por ellos en los comités ante negocio, no serán un Equipo de Desarrollo agile.

Procura además contar con un Scrum Master con cierta experiencia, que no sea demasiado purista y sepa adaptarse a las circunstancias.

Es muy común encontrarse con Scrum Master que se saben de memoria la guía Scrum y que implosionan cuando en la organización en la que trabajan se salen un ápice del camino trazado por ella. No quiero decir con esto que el SM deba hacer oídos sordos a las violaciones del marco de trabajo, digo que debe ser práctico y adaptar Scrum a la idiosincrasia de la organización.

Por tanto debe ser flexible y pragmático, aunque dentro de sus posibilidades se esfuerce en evangelizar y tratar de ser un facilitador del cambio. Veremos la figura del Scrum Master con más detalle en posteriores artículos de Scrum.

Reflexión final

Te he dado la receta de la agilidad. Sencilla de definir, sólo tres pasos, pero difícil de ejecutar.

Si has logrado convencer a la organización de la importancia de respetar los preceptos del agile, aplicas y respetas correctamente un método ágil y tienes un equipo solvente y «empoderado» y alineado con la mentalidad agile, ya tienes gran parte del camino recorrido.

¿Algo más? Por ahora tienes más que suficiente. No te preocupes todavía por las herramientas, ni por Jiras o ni nada por el estilo. Cuando hay voluntad, basta con unos paneles físicos. En siguientes posts iremos refinando nuestra estrategia para que logres aplicar un agile excelente y tus proyectos vayan como la seda.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario