GFT, agilismo y Scrum (I)


Desde hace unos años, en el mundo de la tecnología y del desarrollo de productos y servicios innovadores la palabra agilidad o el concepto Scrum están sonando con fuerza. ¿Pero qué es la agilidad y cuáles son los principios de Scrum? ¿Cómo se aplica? Y lo más importante: ¿qué retos plantea para una empresa como GFT, una consultoría de TI especializada en el sector financiero? Pues bien, en este post vamos a centrarnos en responder a la primera pregunta, dejando el resto para una serie de artículos relacionados con el tema que publicaremos próximamente, puesto que durante el año 2015 GFT dará un paso al frente en este campo.

En 1986 Takeuchi y Nonaka publicaron el Hardvard Business Review un artículo con título “The New New Product Development Game” en el que ya se destacaban los beneficios que grandes empresas como Honda, Canon o Fuji-Xerox estaban obteniendo gracias a la aplicación de modelos de desarrollo de productos all-at-once en los que se recalcaba la importancia de formar equipos multidisciplinares de trabajo con capacidad de autogestión y decisión. Equipos en los que todos los miembros comparten un objetivo final y se encargan de realizar todas las fases requeridas en el desarrollo del producto”. En este artículo ya se mencionaba el concepto Scrum como analogía del Rugby, un deporte en el que los equipos tienen un objetivo común y van trabajando jugada a jugada hasta la consecución del mismo.

A Takeuchi y Nonaka los siguieron Jeff Sutherland y Ken Scwaber, los creadores de Scrum, tal y como lo conocemos hoy. Una definición breve de Scrum sería: conjunto de principios y prácticas que ayudan a los equipos a entregar productos y servicios en ciclos cortos de tiempo, lo cual permite captar rápidamente las opiniones sobre los mismos, llevando así a una mejora continua y facilitando una gran adaptación al cambio.

Tal y como hemos mencionado, Scrum se basa en una seria de principios y valores tales como concentración, coraje, apertura, compromiso y respeto. Por lo que concierne a los principios –en concreto 12, que emanan del manifiesto ágil- éstos son un muy buen resumen del framework de Scrum, que detallo a continuación:

  • Individuos e interacciones en lugar de procesos y herramientas; es decir, la confianza está puesta en los equipos, que son los que deciden qué hay que hacer, cómo hacerlo y finalmente lo hacen.
  • Software funcionando en lugar de documentación extensiva; es decir, el equipo debe centrarse en entregar al final de cada iteración (o sprint) un incremento de producto completo y que funcione. Para ello, en cada una de estas iteraciones el equipo se ocupa de analizar, diseñar, probar y quizás documentar, anteponiendo por encima del resto el funcionamiento del incremento de producto entregado.
  • Colaboración con el cliente en lugar de negociación contractual; para ello el framework de Scrum define el rol de Product Owner (dueño del producto). Este rol representa el punto de contacto principal entre el equipo Scrum y los usuarios finales del producto y las partes interesadas en él. Por tanto esta figura trabajará conjuntamente con todo el equipo Scrum para decidir qué debe realizarse y en qué orden con el fin de que a final de cada iteración el incremento de producto tenga el valor (de negocio) más alto posible.
  • Respuesta al cambio en lugar de seguimiento de un plan; antes comentábamos que uno de los valores de Scrum es “apertura”, lo cual significa que la información es fluida y circula de forma transparente entre todos los miembros del equipo con el fin de que todos puedan tomar las mejores decisiones para el proyecto. Las actividades y herramientas definidas en Scrum facilitan que los equipos puedan “inspeccionar” lo que sucede de forma abierta y “adaptar” sus acciones a la realidad. El siguiente dibujo explica muy claramente este punto de forma gráfica:

 

scrum

En la parte izquierda de la imagen, vemos el rumbo que va tomando un proyecto waterfall o “que sigue un plan” predeterminado al inicio del proyecto. En este proyecto, el cliente ve los resultados finales cuando el equipo se encuentra en este punto, es decir, cuando llega al punto B. El cliente, al ver lo que el equipo ha construido decide realizar cambios en el proyecto, lo que implica tener que trabajar hasta que se llega al nuevo punto final (el punto C). Esto tiene un alto impacto ya que el equipo tiene que reaccionar cuando todo el proyecto está finalizado. Sin embargo, en la parte derecha de la imagen, vemos el rumbo que va tomando un proyecto Scrum, el cual va adaptándose iteración tras iteración, ya que el cliente va revisando la evolución del proyecto al final de cada iteración. Por este motivo, el equipo detecta mucho antes que el cliente lo que realmente quiere es acabar en el punto C en lugar de en el punto B, lo cual minimiza el impacto del proyecto, en comparación con el equipo Waterfall.

Entonces, ¿de qué manera concreta se aplican estos principios y valores de Scrum? ¿Cuáles son los nuevos roles que facilitan la agilidad de los equipos? ¿Qué actividades se llevan a cabo para tener control de los proyectos y al mismo tiempo no impactar la agilidad de los mismos? ¿Por qué una empresa como GFT está adoptando esta filosofía? Encontraréis respuesta a estas preguntas en las siguientes publicaciones sobre el tema, ¡estad atentos!