5 Errores a evitar trabajando con SCRUM en Implementación Agile | Izo
logo_izo

5 Errores a evitar trabajando con SCRUM en Implementación Agile

Blog

“Scrum es un marco de trabajo para implementar proyectos de innovación complejos basándose en la teoría de control de procesos de empirismo. El empirismo asegura que el conocimiento procede de la experiencia y en poder tomar decisiones basándose en lo conocido con un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo.” (La guía de Scrum, 2013).

Las ventajas de una gestión ágil de la innovación con Scrum se centran en el enfoque iterativo, paso a paso, que es ideal para proyectos con un alto grado de innovación, y de entornos inciertos. Al mismo tiempo esto no significa que Scrum es una “varita mágica” que nos solucionará todos los retos que tenemos sobre la mesa y nos llevará al éxito en el 100% de los casos. Bien, podemos aumentar la tasa de éxito de nuestros proyectos de implementación (sean digitales o no) o transformación.

Desde los equipos SCRUM dedicados a la transformación de Customer Experience y Employee Experience, ¿cómo podemos identificar los errores más comunes a la hora trabajar en formato agile?

1. Gap entre la Esencia de Scrum y la Cultura Organizativa

Para la puesta en práctica exitosa de Scrum es esencial estar alineados con los valores y principios de Scrum en combinación con la transparencia, voluntad de cambiar y aprender de forma continua.

Comenzar a trabajar con Scrum, no es simplemente reorganizar roles y equipos de trabajo, sino integrar unos valores y un marco de trabajo en el día a día y estructura actual de la organización. Los aspectos significativos del proceso como por ejemplo el “Definition of Done” deben ser visibles y transparentes para aquellos que son responsables de la implementación.

Podemos decir definitivamente que el reto verdadero no es aplicar las pautas y reglas de Scrum, sino adaptarlos de forma coherente en todos los niveles, y además estos comportamientos deben ser promovidos desde la alta dirección. Para trabajar con Scrum es necesario trabajar en la transformación organizacional y en la forma como los equipos están organizados. Manteniendo estructuras tradicionales como departamentos, la implementación del marco de trabajo se dificulta y encontraremos rápidamente un techo de cristal de la organización.

En un nivel operativo incluso puede ser retador cumplir con una de las reglas principales de Scrum, los eventos de “timebox”. Por ejemplo la reunión diaria (daily scrum) es un evento donde el equipo de desarrollo debe sincronizar sus actividades y planificar las próximas 24 h, con una agenda específica y una máxima duración de 15 minutos.

2. Proyecto Scrum sin aplicar Metodología Centrada en las Personas

Como mencionamos en el inicio del post Scrum es un marco de trabajo de procesos que contiene las reglas de juego, los eventos, los roles y los artefactos definidos. El framework no contempla por defecto una metodología centrado en las personas que es clave integrar si queremos construir lo correcto y lo que el cliente realmente necesita. Lo recomendable es trabajar con un modelo híbrido sacar lo máximo tanto del framework Scrum como de las metodologías Human-centred como por ejemplo Design Thinking.

Este modelo puede llevar más lejos los descubrimientos de Design Thinking, Poner en el centro el cliente y pensar como diseñador, dar suficiente peso al empatizar, entender e idear antes del desarrollo y acelerar el time to market.

3. Equipos Auto-Organizados sí o sí

El framework Scrum nos habla y requiere equipos auto-organizados, pero no podemos ser “talibanes” con el marco de trabajo. Si nuestro equipo desarrollador tiene perfiles juniors van a necesitar apoyo en su trabajo, y de esto se debe responsabilizar el Scrum Master.

Además, para tener éxito con la aplicación del framework necesitamos contar con equipos fijos, si vamos cambiando con frecuencia los miembros del equipo, el equipo de forma continua va a estar en estado de Storming, acorde al modelo de desarrollo de equipos de Tuckman.

En esta etapa tan crítica, el Scrum Master deberá actuar mediante el ejemplo e involucrarse, mostrando un modelo a seguir, para que los miembros del equipo de desarrollo asuman sus responsabilidades.

4. Roles Malentendidos

Antes de empezar a trabajar con Scrum es imprescindible tener claridad sobre los roles que forman parte del equipo Scrum. No todos los roles son para todo el mundo y pueden causar confusión y falta de organización en el equipo.

Como Scrum master no podemos ser Project Manangers, sino nuestro objetivo va a ser velar por el cumplimiento del proceso ajustando las reglas y prácticas del scrum siempre buscando las mejoras aplicando las sesiones de Retrospective. Debe ser un buen mentor apoyando tanto al equipo de desarrollo como personas externas involucradas de forma puntual.

Mientras como Product Owner debemos maximizar el valor del producto y el trabajo del Equipo de Desarrollo. Es un perfil que conoce muy bien al cliente y los requisitos del producto, gestiona y prioriza los requisitos del backlog y controla el desarrollo. Por lo tanto, el Product Owner debe estar disponible en todo momento cuando le necesita el equipo o bien el cliente.

5. Proyecto Ágil no Equivale a Proyecto Rápido

Dada la naturaleza de un proyecto ágil implementado con Scrum, la planificación se mueve a primer plano y tiene un protagonismo que nos acompaña a lo largo de todo el proyecto. Con la aplicación de Scrum dividimos los objetivos del backlog de proyecto en sprints más cortos donde al terminar un hito siempre debemos construir y entregar un incremento, esto no necesariamente se refiere a un entregable definitivo MVP, pero un avance tangible sí.

A la hora de planificar el proyecto tenemos que considerar la magnitud de lo mismo y fijar la duración de los sprints. Un proyecto de un año es raro que tenga sprints de 1 semana, más bien de 4 semanas. Además, para generar rutina y medir la productividad todos los sprints deben ser igual de duración.

Conclusiones

Para poder transformarse en una organización ágil y beneficiarse de las ventajas del método agile y Scrum, se deben vivir y aplicar las reglas básicas de la gestión ágil, así como los principios y valores del Scrum. Por lo tanto, Scrum no debe entenderse como una herramienta de gestión de proyectos, sino como un método ágil cuya aplicación requiere una adaptación integral de la cultura corporativa y de la compañía.

0.88