Scrum, Kanban, Lean, SAFe, LeSS, DA, Scrumban, son un ejemplo de la diversidad de modelos que tenemos a nuestra disposición para aplicar los principios del agilismo como metodología de desarrollo software. La adopción de estos modelos responde en muchos casos a modas por las que ciertos términos se popularizan y empujan a las organizaciones a realizar cambios en sus procesos y técnicas.

Pizarra Kanban básica (fuente Wikimedia)

Manifiesto ágil: la importancia de sus valores

El efecto de aplicar estos modelos solo por el hecho de estar de moda puede ser que esta adopción resulte forzosa y no adecuada a la realidad de cada organización y su software, olvidando que, aunque las metodologías pueden ayudar a la mejora del desarrollo, los valores originales del agilismo se pueden encontrar en el Manifiesto ágil:
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

  • 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

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
Este manifiesto fue elaborado y firmado en 2001 por varios de los expertos en desarrollo software del momento, y a la vez supuso la formación de la Agile Alliance como una organización sin ánimo de lucro para servir de centro que profundizase en las metodologías ágiles.

Origen de las prácticas ágiles

Dado que este manifiesto fue el fruto de la reflexión sobre años de trabajo de sus firmantes, es importante resaltar que muchas de las prácticas del agilismo vienen realizándose desde décadas atrás.

Historia del agilismo (fuente Wikimedia)

Lean programming es más reciente (2001), pero sus ancestros, Lean manufacturing y Toyota Production System (TPS), provienen de la segunda mitad del siglo pasado, y resultan básicos para entender muchos de los principios del agilismo. Los dos pilares básicos del TPS son:

  • JIT (Just-in-time), “hacer solo lo que es necesario, solo cuando es necesario y solo en la cantidad que es necesario”.
  • Jidoka (Autonomation), “automatización con un toque humano”.

JIT es el origen de métodos de organización y planificación de tareas como Kanban, y también la inspiración para el concepto de sprints en Scrum. Jidoka pone el foco en controlar la calidad automatizando todo lo que sea posible, pero con un equipo de personas siempre supervisando e investigando el origen de los problemas para mejorar la automatización; o lo que es lo mismo, el origen de los procesos de pruebas automáticos de software y el concepto de cobertura de código.

Scrum como estándar de facto, ¿vale para grandes organizaciones?

Scrum tarda un poco más en aparecer en escena, y sus bases se asientan cuando en 1986 Takeuchi y Nonaka publican su artículo The New New Product Development Game en Harvard Business Review. El artículo describe un enfoque similar al rugby en el que “el proceso de desarrollo de producto surge de la interacción constante de un equipo multidisciplinar seleccionado cuidadosamente, cuyos miembros trabajan juntos desde principio a fin”. En 1993, Jeff Sutherland inventa formalmente el proceso Scrum, adoptando muchas otras prácticas ya en uso, como las Stand-up meeting (reuniones de pie) diarias, y con el paso del tiempo se convierte en un estándar de facto para muchas organizaciones que deciden incorporar metodologías ágiles a sus desarrollos de software.

Ciclo de vida Scrum (fuente Wikimedia)

Los detractores no tardan en aparecer y muchos se centran en la idoneidad de la metodología para pequeñas organizaciones tipo start-up, pero no tanto para organizaciones grandes. Como respuesta a esta crítica surge el concepto de Big Agile, haciendo escalado de Scrum, con frameworks como SAFe (Scaled Agile Framework) o LeSS (Large Scale Scrum), que ayudan a realizar una gestión integral ágil, no solo a nivel de proyecto, sino también de programa y portfolio.

 

Fuente: LeSS Framework

Agilismo adaptado a las necesidades de cada organización

La estandarización de Scrum como marco de trabajo en el desarrollo de software no ha impedido la popularidad de otras metodologías como Kanban, para los casos de desarrollo más enfocado al mantenimiento que al proyecto. También han emergido otras variantes que suponen una innovación sobre dichos modelos, como por ejemplo:

  • Scrumban: mezcla lo mejor de Scrum y Kanban, en la que se pueden dar casos como una pizarra Kanban con marcos temporales planificados (i.e. sprints).
  • Dual Track Development: establece dos vías de trabajo paralelas, una dedicada al descubrimiento (Discovery track) y definición de nuevas funcionalidades y otra al desarrollo y entrega (Delivery track) de los productos con dichas funcionalidades; más información en este interesante artículo sobre cómo configurar Jira con Dual-Track Scrum.
  • Modern Agile: redefine los principios del manifiesto ágil, tratando de huir de grandes frameworks y la burocracia excesiva que se está generando alrededor de las metodologías ágiles que ya llevan un tiempo implantadas, como es el caso de Scrum.
Fuente: Modern Agile

La aparición de prácticas como DevOps o UX, en las que es necesario implicar a los equipos de operaciones y diseño en todo el ciclo de vida del desarrollo software, o el aumento en la tendencia de la deslocalización de los equipos, están provocando que las organizaciones sientan que en sus procesos de transformación digital es necesario adoptar metodologías ágiles para su funcionamiento, pero haciendo pequeños arreglos (process tailoring) a la metodología que se adapte a sus necesidades, tal y como se promueve en el DA (Disciplined Agile Framework).

Como conclusión, es muy importante que estos procesos de cambio estén basados en los valores del manifiesto ágil, y que sepan adaptarse a los objetivos de cada organización para conseguir un equilibrio entre metodología y necesidades, poniendo agilismo por delante de las etiquetas.

Entrada elaborada por Roberto Clemente , Analista coordinador