Dos problemas que resuelve el marco Scrum

En el post anterior les comenté algunos problemas que pueden hacer fracasar un proyecto cuando se gestiona de forma tradicional, puede leerlo aquí: Planificaciones que no se cumplen ¿Un problema para ti?. Hoy escribiré sobre cómo el marco de trabajo Scrum facilita y minimiza algunos de estos problemas.

Dos de los principios fundamentales de Scrum son la transparencia y la retroalimentación continua. La información relevante del proceso esté asequible para todos los implicados en el desarrollo y todos pueden comprender la misma. A través de los eventos definidos por Scrum, tanto el cliente como el equipo mantiene una retroalimentación constante del estado del trabajo, así como de la validación de los entregables. Veamos como con Scrum puede garantizarse una adecuada interacción con el cliente.

Interacción defectuosa con el cliente

El marco de trabajo Scrum, define tres roles para facilitar la práctica del desarrollo ágil: El DUEÑO DEL PRODUCTO, EL SCRUM MASTER y EL EQUIPO DE DESARROLLO.

El Dueño del producto, es el encargado de representar los intereses del cliente. Esta persona se encarga de velar que el equipo comprende el trabajo que se desea, que persigue la misma meta y es el responsable de elaborar el Product Backlog; también es el máximo responsable de obtener el mayor rendimiento de la inversión.

El Scrum Master será el responsable de velar por el cumplimiento del proceso Scrum, se asegura que todos sigan y comprendan las normas y prácticas de Scrum, elimina los impedimentos y obstáculos que pueden atentar contra el éxito del equipo.

El Equipo de Desarrollo es el encargado de desarrollar los elementos definidos por el Dueño del Producto por cada Sprint y entregar las funcionalidades implementadas al final de estos. Es responsable de cumplir estos compromisos.

Ahora bien, la forma en que el marco de trabajo Scrum se asegura de tener una interacción adecuada con el cliente, es a través del rol Dueño del producto.

El Dueño de Producto es una única persona, no un comité, ni un grupo de interesados, ni representantes de diferentes áreas del cliente. El Dueño de Producto podría representar los deseos de esos interesados en la Lista del Producto, pero aquellos que quieran cambiar la prioridad de un elemento de la Lista deben hacerlo a través del Dueño de Producto.

Para que el Dueño de Producto pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones. Las decisiones del Dueño de Producto se reflejan en el contenido y en la priorización de la Lista del Producto. No está permitido que nadie pida al Equipo de Desarrollo que trabaje en un conjunto diferente de requisitos y el Equipo de Desarrollo no debe actuar en lo que diga cualquier otra persona.

Con la existencia del Dueño del producto, Scrum se asegura de establecer un proxy, una interfaz única de comunicación y se evita así el problema de tener muchos canales de comunicación con diferentes interesados, ni clasificarlos según su influencia o poder, o interés en el producto a desarrollar. Libera así al equipo de tener que establecer a qué interesados mantener satisfechos, a cuales solo debe informar o que solicitudes atender y cuales no.

Comunicación efectiva

Scrum propone cuatro eventos formales, contenidos dentro del Sprint, para la inspección y adaptación:

• Planificación del Sprint (Sprint Planning)
• Scrum Diario (Daily Scrum)
• Revisión del Sprint (Sprint Review)
• Retrospectiva del Sprint (Sprint Retrospective)

A través de estos eventos, se garantiza la comunicación efectiva y la interacción adecuada entre el Dueño del producto, el Scrum Master y el Equipo de Desarrollo.

Algo que hay que tener presente para no caer en un error al implementar Scrum es que un equipo Scrum no funciona bien cuando no se identifica un Dueño del Producto, sino a un grupo de usuarios funcionales, que tienen diferentes visiones del producto a desarrollar y que representan a diferentes áreas del cliente.

Agradeceré cualquier comentario o experiencia que quieras compartir.