IMPLEMENTANDO SCRUM POR PRIMERA VEZ

Tantas cosas bonitas que se oyen hablar de Scrum, aclarando que no es una metodología sino un marco de trabajo, vamos a implementarlo por primera vez en una empresa. Pero cuales son los principales obstáculos que nos podemos encontrar? Vamos a explicarlos.

El escepticismo del equipo en metodología ágiles. Según lo que se conoce scrum ha funcionado en otras compañías. El equipo puede sentirse incómodo con la utilización de nueva terminología, sentirse presionado o no adaptarse a los procedimientos y eventos que se presentan. Podemos emplear una terminología adaptativa para que sin salirnos de scrum lo podamos implementar contando con un equipo con baja resistencia.

La cantidad de eventos tan seguidos y continuos. El equipo puede pensar que más reuniones son más seguimiento al trabajo y en parte es verdad, pero también el equipo que no tiene fe en scrum, puede creer que las reuniones son solo perdidas de tiempo.

Tenemos un equipo poco autogestionado. Es un requisito para las metodologías ágiles, los equipos deben ser autogestionados y autónomos, deben tomar sus propias decisiones siempre que estas decisiones los acerque mas al objetivo de cada sprint.

La infraestructura de la empresa en el área de TI. Scrum para desenvolverse requiere involucrase directamente con el usuario, tanto que es el usuario quien ordena y  prioriza las tareas de cada uno de los sprints al usuario. Esto cambia completamente la estructura de proyectos donde un usuario hace el requerimiento y al cabo de un tiempo le informan que quedo terminada su solicitud. A parte de todo, este proceso se volvió burocrático y podemos encontrar mucha resistencia de las personas que gestionan esa burocracia.

Errada definición de terminado. Esta debe ser conocido y aceptados por el equipo de proyecto. Lo que para el equipo de desarrollo esté terminado, para el dueño de producto no. La definición del criterio de aceptación debe ser muy clara para todos los miembros del equipo de desarrollo.

Seleccionar mal el dueño de producto. el dueño de producto puede cambiarse, ser originalmente alguien de TI, pero debe terminar en manos del dueño del proceso quien es quien debe maximizar el valor del producto.

Otro riesgo es la cultura, la adaptación de estas metodologías debe imprimir un fuerte cambio en la cultura. Los requerimientos se están convirtiendo en un formalismo, pero solo por cumplir, lo que el usuario quiere implementar nunca estuvo en documento alguno. El cambio más fuerte de esta metodología puede estar en la cultura. Es tal y como lo muestra el documento de Kenrik Kniberg  en el libro Culture over process. (dejo link con video)

link

Finalmente, la implementación de scrum deberá al principio intentar seguirse al pie de la letra según como menciona la guía de scrum y poco a poco adaptar lo que se requiera para conseguir resultados con este marco de trabajo.  

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *