Formar equipos ágiles cuando estás empezando en Scrum

Tu compañía ha decidido aplicar Scrum para transformar el proceso de desarrollo de producto e intentar mejorar así la agilidad organizacional. Pero nadie tiene claro como empezar a hacerlo.

Quizás hayáis recibido formación o quizás hayáis visto algunos videos de introducción a Scrum. En cualquier caso hay dudas sobre cuales son los pasos adecuados. Esta guía te ayudará a enfocarte en los puntos correctos y ahorrarte quebraderos de cabeza.

Asegurate de que tienes un compromiso de la organización para acometer el cambio

Lamentablemente, es muy normal ver cómo hay compañías que intentar implementar Scrum y hacen un gran esfuerzo, sólo para descubrir que tienen todo en su contra. Hay autores como Mike Cohn que abogan por un «Stealth Scrum», lo que puede funcionar con muchas limitaciones.

Es mejor si existe un compromiso expreso de dar una oportunidad al framework. Lo mejor es empezar con un proyecto pequeño. Que no sea crítico para la organización pero que no sea tan irrelevante como para que a nadie le importe el éxito del mismo.

Selecciona un Product Owner, la persona responsable del desarrollo del producto

Este es el primer paso fundamental para hacer Scrum. Nombrar a alguien para que sea el representante de las necesidades de negocio y que actué de Product Owner de negocio. El Product Owner se va a encargar de preparar un backlog priorizado para desarrollar. Es probable que al principio sus responsabilidades también toquen las de Product Management, aunque si puede trabajar con un Product Manager es mejor.

Evita:

• Los comités de personas que deciden el Product Backlog
• Una persona que no pueda dedicar el 100% de su tiempo al desarrollo
• Alguien que realmente no tenga autoridad.

Si Scrum es bueno en algo, no es en agilizar organizaciones, sino en hacer transparentes los verdaderos problemas de las mismas. Si en tu organización el management no tiene el liderazgo suficiente para tomar una decisión de ese calibre, deberías de enfocar el esfuerzo en eliminar ese impedimento antes de seguir.

Resolver estos impedimentos ayudará a incrementar la agilidad organizacional.

El Product Owner tiene que buscar al equipo de desarrollo

Ya sea mediante voluntarios o mediante convencimiento uno a uno, el Product Owner debe buscar al equipo en el que va a confiar e invertir para desarrollar el producto. Recuerda, el PO es el último responsable del retorno de la inversión de ese equipo, así que es quien debe tomar la decisión de trabajar con equipo con el que se sienta cómodo.

Evita:

• Seleccionar al PO por un lado y al equipo por otro y decirles que trabajen juntos.
• Coger gente de aquí y de allí sin saber que tienen todas las skills necesarias para entregar software terminado.
• En general, cualquier atajo que no sea reconocer la situación de tu organización.

¿Cómo decide el PO quien es el adecuado para formar el development team? Fácil. El Development Team tiene que tener de 3 a 9 miembros que tengan todas las habilidades necesarias para entregar un incremento terminado de Software, por pequeño que sea. Es el propio equipo y las personas técnicas de la organización quienes ayudaran al PO a entender esto.

El equipo de desarrollo busca a un Scrum Master

El papel del Scrum Master es dar servicio al equipo de desarrollo y gestionar Scrum. Éste responde exclusivamente al equipo de desarrollo y trabaja para mejorar el uso de Scrum y aumentar el valor del producto.

Evita:

• Seleccionar a un Scrum Master que nunca haya hecho Scrum.
• Reutilizar una persona existente sin experiencia. Sólo volverá a lo que hacía antes
• Pasar del Scrum Master porque no es justificable.

Comienza con Scrum

Cumplir estos elementos te llevará unas semanas. Durante este tiempo, las personas de tu organización se irán acostumbrando a escuchar hablar de Scrum y eso es positivo. Una vez que todo el mundo esté preparado y el Product Owner tenga claro cual es el Sprint Goal del primer Sprint, podéis comenzar con el primer Sprint Planning.

Evita:

• Sprint 0. No existe en Scrum y es una práctica que sólo sirve para reafirmar los modelos en cascada. Demuestra inmadurez.
• Intentar hacer predicciones. Por mucho que quieras predecir que va a pasar, sólo el histórico de incrementos terminados te dará datos reales.
• Presionar a través de la motivación. Lo mejor es dejar que el equipo haga al ritmo que puedan. Intentar presionar a través de una falsa motivación sólo llevará a la frustración.

Llegado este momento, ya habrás hecho un largo recorrido de cambio que habrá hecho que, en general, aumente la agilidad organizacional. A partir de entonces se abre un abanico muy amplio de opciones que tendréis que ir explorando utilizando los tres pilares de Scrum: Inspección, Adaptación y Transparencia.

Quizás después de leer esto pienses que no es posible hacer Scrum así, que necesitáis adaptarlo. Este es un atajo común que muchas organizaciones siguen y es, sin duda, el más costoso, doloroso y caro que hay. No afrontar los problemas de forma temprana llevará a perpetuar un modelo basado en la incertidumbre y la baja calidad si cabe aún durante más tiempo.