Scrum es una metodología muy transparente, donde todo se hace a plena luz para ser visto por todos. Siguiendo el espíritu de Scrum, todo está abierto para que los interesados lo miren.
- Los requerimientos tienen que estar detallados antes de la planificación del sprint, el equipo puede rechazar un elemento del backlog del producto si no está completo.
- Los desarrolladores tienen que dar una estimación oficial para cada elemento.
- Los gráficos de burndown del sprint muestran el progreso del sprint actual, el cual debe estar en la pared, cerca del lugar de trabajo de los desarrolladores.
- El Scrum Diario tiene que ser en un lugar abierto para que cualquier interesado pueda unirse a escuchar.
- El resultado del sprint se muestra públicamente, por los mismos desarrolladores.
Este alto grado de transparencia provaco que nadie pueda esconderse en un proyecto con Scrum. Se muestran los éxitos, y también los fracasos. Y está bien que sea así. De esta manera nos aseguramos que los problemas se encuentren y resuelvan lo antes posible.
El Dueño del Producto a la vista
El Dueño del Producto está a cargo del backlog del producto. El backlog del producto es la base para la reunión de planificación del sprint. Si el Dueño de Producto no hizo bien los preparativos, va a resultar obvio durante la reunión de planificación cuando los desarrolladores comiencen a hacer preguntas sobre las tareas.
Los representantes del cliente a menudo intentan apurar al equipo a mentener un deadline ajustado. Desafortunadamente, a veces esta fecha de deadline es lo único que tiene en claro el cliente. Pueden resultar poco precisos los objetivos del proyecto, las historias de usuario y los detalles de los requerimientos. Adivinen si puede desarrollarse algo si el cliente no puede decir lo que necesita...
Aquí es donde la transparencia en Scrum ayuda a identificar el problema. Sin Scrum, los requerimientos de baja calidad terminan resultando en desastres durante la fase de construcción. Con Scrum, el Dueño del Producto tiene que mostrar claramente lo que necesita antes de empezar el sprint, sino esa tarea en particular se postpone para el siguiente sprint. No se aceptan los "requerimientos con detalles casi listos". Al momento de la planificación del sprint, o el item del backlog está bien detallado, o no lo está. Sino lo está, no se incluye en el sprint.
Este es uno de los motivos por lo cual a los desarrolladores les gusta Scrum. Le da a los desarrolladores la posibilidad de rechazar los requerimientos poco precisos. Sin esta posibilidad, los requerimientos poco claros se terminan usando para desarrollar, y cuando se entregan resultados inservibles se culpa a los desarrolladores.
Estimación de desarrollo a la vista
Para la mayoría de los desarrolladores, la peor pregunta que les pueden hacer es pedirles que estimen el tiempo. Seguramente esta es la parte que más miedo ocasiona Scrum para quienes empiezan: tener que dar una estimación oficial de tiempos.
Existe un factor de mitigación para las estimaciones de tiempo en los proyectos de Scrum. Los desarrolladores que trabajarán son quienes realizan esta estimación. No hay lugar para un líder con una agenda poco realista que fuerce una estimación al equipo. El equipo tiene la libertad de dar la estimación en la que crean. Esta libertad genera responsabilidad. El equipo es el responsable de sus estimaciones.
Avance del desarrollo a la vista
Durante el sprint, se realiza un seguimiento del progreso usando un gráfico de burndown. También hay reuniones diarias de parado (los scrum diarios) en donde cada desarrollador explica lo que hizo ayer, lo que va a hacer hoy y si hay algún impedimento. Este burndown visible hace imposible que se oculte el progreso. Está visible inmediatamente para todos.
Y esto es bueno, porque uno de los problemas más serios y comunes en los proyectos es cuando las personas empiezan a ocultar el avance real, para que aparente estar siguiendose un plan. Cuando se revelan las mentiras suele ser ya muy tarde para volver al plan original. Con Scrum, cualquier demora se visualiza inmediatamente y se pueden tomar acciones.
Resultados del desarrollo a la vista
Al terminar un sprint, los desarrolladores muestran lo que lograron. Personalmente. Frente al cliente. En mi experiencia, esta es una de las partes más importantes de Scrum. Establece una relación y compresión entre los desarrolladores y los clientes. Como humanos, tendemos a hacer un esfuerzo extra por quienes conocemos. Si tenemos una relación directa con el cliente, los desarrolladores harán ese esfuerzo extra. Y este esfuerzo es el que puede hacer la diferencia entre un proyecto exitoso y otro no tanto.
Sin lugar para esconderse
Scrum no es para quienes quedarse para ellos lo que hacen. Al contrario, muchos de los hábitos de Scrum apuntan a incrementar la transparencia. Gracias a la transparencia todos los involucrados saben lo que ocurre. Cuando todos saben, todos pueden ayudar si existe algún problema en cualquier lugar del proyecto.
