Metodologías Ágiles, Scrum: errores y recomendaciones

Hoy en día, y más en desarrollo de software, todo el mundo habla de agilismo, de ser lean, de aplicar Scrum... De lo que son y del cambio que han supuesto; de sus ventajas y casos de éxito.

No hay duda de que los beneficios de emplear este tipo de metodologías son muchos y de sobra conocidos, pero, siendo sinceros, no siempre es algo sencillo.

Aunque pocos lo cuentan, aplicar Scrum también tiene sus complicaciones y como para nosotros esto no es excusa, hemos querido explicarte dónde hemos estado encontrando obstáculos y cómo estamos trabajando para salvarlos.


Be Agile, My Project. Recomendaciones y buenas prácticas al trabajar con Scrum

El pasado jueves 19 de enero, nos reunimos en el CIBBVA para enseñarte la otra cara de la moneda, la que no te cuenta nadie.

Una tarde de microcharlas en la que nuestros cracks cubrieron todo el ciclo de desarrollo: desde el Product Owner hasta el Scrum Master, sin dejar de lado al Equipo de Desarrollo:

David Díez, Developer Manager en Intelygenz, fue el encargado de abrir las charlas de “Be Agile, My Project” explicando nuestra metodología de trabajo en el camino para convertirnos en una referencia del desarrollo ágil de software. David nos dejó caer dos enseñanzas:

  • En primer lugar, contar con una estructura muy clara y con muy poco nivel de jerarquía formada por el Equipo de Desarrollo, el Scrum Master y el Director de Operaciones.
  • Y, en segundo lugar, no confundir un Jefe de Proyecto con un Scrum Master, puesto que la filosofía en el desarrollo de trabajo puede ser completamente diferente.

Implementar Scrum no es algo pueda hacerse con éxito de un día para otro y, en este caso, el nivel de incertidumbre tiende a ser mayor que en otras metodologías como en waterfall o cascada.

En Intelygenz, no lo vamos a negar, hemos cometido errores y seguimos cometiendo muchos, pero vamos a lo práctico ¿cómo lidiamos con ellos?


La visión del
Scrum Master

David comentó su visión explicando que hoy en día todo el mundo dice ser ágil y más en el mundo del desarrollo de software, pero que a menudo se confunden el concepto y planteamiento de agilismo:

Error nº 1. Ser ágil no es sinónimo de ser rápido, ni de emplear pocos recursos. Los principios del Manifiesto Ágil indican que la principal prioridad en el desarrollo de software es hacer una entrega continúa con el fin de aportar software de valor y aceptando que se darán cambios y que adaptarnos a éstos puede suponer una ventaja competitiva. O lo que viene siendo, “hacemos agile porque consideramos que es la mejor manera de alcanzar la satisfacción del cliente (en un entorno cambiante)”.

Error nº 2. Llegar a perdernos en la gran cantidad de conceptos y prácticas que implica el agilismo. Para no caer en este error la mejor recomendación es la de mantener la simplicidad : velar por la buena gestión del “Product Backlog”, llevar una adecuada gestión del “Sprint Planning” y, en último lugar, no dejar nunca de lado la retrospectiva.

Error nº 3. Creer que si tienes todo controlado nada puede fallar. El desarrollo de software implica cambio y es una máxima que el Scrum Master tiene que saber asumir anticipándose a los problemas, dando visibilidad a las situaciones, sabiendo resolver conflictos y comunicando.

Visión del Scrum Master


La visión del Equipo de Desarrollo

Juanfi (Juan Rafael Pérez), desarrollador Fullstack en Intelygenz, se encargó de darnos la visión del Equipo de Desarrollo a la hora de trabajar y superar las principales complicaciones derivadas del trabajo con Scrum:

Error nº 4. Trabajar con equipos muy estructurados y muy numerosos. Lo ideal a la hora de trabajar con Scrum es formar equipos de entre 5 y 9 personas, con perfiles multidisciplinares de manera que las entregas no se vean condicionadas y la comunicación se mantenga fluida.

Error nº 5. No contar con conciencia de equipo. O dicho de otra forma “un bote no va hacia delante si cada uno rema en su propia dirección”. ¿Cómo logramos crear conciencia de equipo? Trabajando una buena comunicación en la que todos los miembros del equipo tengan visibilidad, con sincronizaciones diarias y evitando los silos de información.

Error nº 6. No ser capaces de trabajar con equipos autogestionados. Los desarrolladores tienen que tener claro que no todo su tiempo es para el desarrollo sino que este también incluye huecos para meetings, el sprint planning… Y, por supuesto, hay que ser crítico y honrado, no puede ser que nada falle y nada se pueda mejorar.

Visión del equipo de desarrollo


La visión del Head of Dev

Alberto Vadillo, Responsable de Operaciones de Intelygenz, se encargó de darnos su visión a la hora de lidiar con las complicaciones que puede suponer el empleo de Scrum para un Head of Dev, más cercano a la figura del cliente (venta, entrega y garantía).

Error nº 7. Vender el Scrum y metodologías ágiles por el simple hecho de que están de moda. Lo correcto para mitigar el riesgo de un “waterfall” encubierto será realizar sesiones formativas sobre qué es Scrum y cómo lo aplicaremos; implicar al cliente y al Product Owner en el desarrollo y guiarnos por un roadmap.

Error nº 8. No cumplir con lo que el cliente pedía en su RFQ o RFP. Para evitarlo una vez más, tendremos que hacer partícipe al cliente en todo momento del proyecto, ayudándole a que tome las decisiones correctas centrándonos en darle valor al producto, no tener miedo de pedir más presupuesto/tiempo al cliente si sus requisitos lo exigiesen.

Error nº 9. No ser capaces de ofrecer una garantía al terminar el desarrollo. En nuestro caso, las soluciones al respecto son intentar siempre ir resolviendo incidencias de sprint a sprint, dedicar un 20% de un sprint al final del proyecto o incluir equipos con otras metodologías para llevar a cabo una evolución del producto (Product Evolution).

Como podrás ver, al final, lo que preocupa a cada uno de los distintos roles dentro de la metodología Scrum es distinto, sin embargo, hay un conjunto de buenas prácticas que nuestros tres cracks nos recomendaron mantener:

  • Ten siempre presentes los principios del Manifiesto Ágil.
  • Evoluciona, poco a poco, pero evoluciona.
  • Mantén un toque optimista para hacer de cada problema una oportunidad.

Como siempre, te dejamos con el vídeo de la charla en nuestro canal de Youtube para que no pierdas detalle y si quieres saber más acerca de cómo implementamos Scrum en Intelygenz te recomendamos que no te pierdas el artículo de nuestro compañero Diego Romera “Aplicando Scrum, claves ágiles sobre esta metodología”.


Próximo meetup: Haciendo el (Chaos) Monkey

Por cierto, dentro de nada volveremos a vernos en un nuevo meetup “Haciendo el (Chaos) Monkey” en el que Alejandro Guirao nos contará cómo Netflix desarrolló el concepto y la tecnología para hacer Chaos Monkey y así comprobar que su infraestructura y código era tolerante a todo tipo de fallos en producción.

Te esperamos el el jueves 2 de febrero a las 19.30h en el CIBBVA, ¡hasta entonces!

¿Te gustaría trabajar con nosotros? Genial ¡te esperamos!