Pages Menu
Categories Menu

Posted by on Mar 27, 2015 in General | 0 comments

¿Quieres saber por qué Scrum en tu empresa no está funcionando tan bien como debería? Parte 2: ¿Agilidad y Scrum son lo mismo?

La semana pasada vimos qué es la agilidad (¿Quieres saber por qué Scrum en tu empresa no está funcionando tan bien como debería? Parte 1: La importancia de las personas.). Ahora te preguntarás, ¿Scrum es agilidad?

Mi percepción es que hay empresas que escuchan hablar de agilidad, metodologías ágiles y lo primero que se les viene a la cabeza es Scrum, porque es de lo que más se habla. Después, lo implementan en su empresa y piensan que así ya son ágiles.

En estos casos es muy probable que mejore su situación con respecto a como estaban antes, pero tarde o temprano, acaban decepcionándose porque eso no era lo que les habían prometido por agilidad.

¿Sabes por qué pasa eso? Porque Scrum, por sí solo, es una forma de gestionar proyectos, nada más. Puedes implantar Scrum sin ser ágil, y por ello, implantar Scrum no implica volverse ágil.

No obstante sí que es cierto que puedes utilizar Scrum, junto con otras técnicas y prácticas de Ingeniería del Software, para lograr llevar a tu día a día los principios y valores ágiles.

Por ejemplo, un valor ágil es la importancia de las personas e interacciones entre ellas. Scrum se preocupa de ello al darle mucha importancia al equipo, a que sea multifuncional y colaborativo, pero para ser realmente ágil, hay que cuidar cómo son las interacciones con otros roles, coordinar bien al equipo, que esté motivado… Muchas cosas que Scrum por sí solo no tiene en cuenta, y vienen más del lado de la cultura de empresa.

Otro valor es la mejora continua, que Scrum lo lleva implícito en las reuniones de retrospectivas.

O la idea de colaborar con el cliente, teniendo la figura del Product Owner.

Pero la herramienta no lo es todo. Por eso escucharás que es imposible implantar un Scrum teórico en todas las empresas, y que hay que adaptarlo. Hay que adaptarlo a tu empresa, cumpliendo los valores ágiles.

Tener una pizarra con post-it, gráficos burndowns etc. no te vuelve ágil. En las empresas realmente ágiles, esto es la superficie de una cultura de empresa tremendamente fuerte y centrada en las personas.

Para mí, lo más productivo es centrarse primero en que la cultura de empresa sea ágil, y que Scrum sea una herramienta que ayude a adoptar ciertos valores ágiles. Y por lo general, no se suele empezar por esta parte.

Ejemplos de que has implantado Scrum, pero no eres ágil.

En muchas empresas en las que solo se implanta Scrum (y que quieren ser ágiles), se dan casos como estos:

No hay colaboración entre el cliente y el equipo. El cliente siempre pide cosas para ayer, todo es importante e impone fechas inamovibles e imposibles de entrega, todo por el mismo precio y negociando cada punto y coma del contrato. Todo eso se impone al equipo de desarrollo, haciendo las horas extra necesarias para conseguirlo.

Esto podría ser un engendro de Scrum, ya que aquí tienes roles definidos y a un representante del negocio en el equipo. Pero no es ágil. Estás incumpliendo el valor de colaboración entre los clientes y el equipo.

La agilidad implica un cambio en la forma de contratación. El cliente y el proveedor deben colaborar entre sí. Por ejemplo, el equipo se compromete a entregar pequeños incrementos del producto que quiere el cliente cada semana y acepta que no tenga del todo claro qué es lo que quiere. Digamos que la empresa es flexible a la hora de gestionar los cambios y aceptar la incertidumbre. A cambio, el cliente irá priorizando en cada caso lo que va queriendo, y si hay que rectificar, se puede llegar a actualizar el contrato, el precio, etc.

– No se valora a las personas. Esto es un clásico. Tenemos los roles de Scrum, pero los equipos están desmotivados y no se les deja actuar con creatividad, ya que hay una actitud de management tradicional de mandar y controlar, de que cuanto más tiempo pases sentado en la silla más productivo eres, etc.

– El equipo no es maduro. Hay ciertas prácticas ágiles que necesitan que el equipo sea profesional y maduro. Mob programming es un buen ejemplo de ello. Es una técnica muy efectiva, pero un arma de doble filo si el equipo no se toma las cosas en serio; si lo haces mal con las personas equivocadas, puedes llegar a tener a 5 personas viendo vídeos de gatitos en Youtube.

– Hay falta de liderazgo. Esto es otro clásico y un síntoma de no entender bien qué es un equipo ágil, multifuncional y autoorganizado. Tener un equipo multifuncional no es sencillo. Puedes tener suerte y que todo surja por sí solo, pero en la mayoría de los casos, no es algo que surge solo, y mucho más si el equipo está formado por gente acostumbrada a trabajar de la forma tradicional. Es completamente normal. Por eso, en muchos casos necesitas un facilitador, alguien que fomente buenas prácticas, resuelva conflictos y promueva actitudes que finalmente harán que el equipo sea multifuncional (pair programming, etc.).

-Falta de empatía entre distintos roles de la empresa. Otro clásico. En una fábrica, la gente que está en la cadena de montaje puede estar separada de la gente de negocio y de la gente de calidad y no llegar a entenderse. Esta visión, de que el desarrollo software es parecido a la construcción de cosas físicas es algo que se extendió al mundo del software.

Pero el mundo del software no es así (Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas (1/2)).

El manifiesto ágil recalca la importancia de la colaboración y empatía entre las personas (desarrolladores, testers, Product Owners, negocio, etc.). Al final, todos los roles son importantes y la empresa es un equipo que debe lograr el mismo objetivo: crear un buen producto que satisfaga al cliente.

Un síntoma de implantar mal la agilidad es que cada rol no sepa lo que hacen otras personas de la misma empresa, otros equipos, que no haya comunicación y que se menosprecie el trabajo de los demás.

Personalmente, esto lo noto muchísimo cuando se menosprecia la función del testing y de la calidad del software en general.

Resumiendo, ¿qué debería hacer para ser ágil?

Scrum, Kanban, etc. son herramientas, y sí son importantes, pero no son un fin en sí mismo, son un medio, en este caso para conseguir la agilidad.

Para ser ágil, y tener éxito en la implantación de muchas prácticas ágiles necesitas empezar por adoptar los valores y principios ágiles en tu empresa.

Puedes llevar en paralelo la adopción de Scrum, de herramientas de gestión (Jira, tableros físicos, etc.), buenas prácticas técnicas imprescindibles (calidad de código, Integración Continua, automatización de pruebas, etc.). Pero no te olvides de las personas y la cultura de empresa.

Ana M. del Carmen García Oterino

Ana M. del Carmen García Oterino

Ingeniera Software QA at BQ
https://www.linkedin.com/in/amgarciao

Apasionada por la calidad del software (procesos, producto y equipos) y buenas prácticas en general.

Especializada en testing, automatización de pruebas e integración continua.
Ana M. del Carmen García Oterino

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This