La gerencia comenzó a implementar Scrum para mejorar la habilidad de presentar nuevas características a los clientes. En el primer Sprint del primer proyecto, los equipos de Scrum entregaron más funcionalidad de la comprometida. Todos, desde la gerencia hasta los clientes, estaban más que contentos con el cambio.

En el segundo Sprint, las cosas cambiarian...

Para el segundo Sprint, los equipos de Scrum se comprometieron a una gran parte del Backlog del Producto. A las dos semanas del Sprint, los equipos se dieron cuenta que estaban en problemas. Cuando los equipos se juntaron, todos sufrian el mismo tema: la funcionalidad era bastante más compleja y difcil que en el primer Sprint. De las 24 partes de funcionalidad que los equipos se habían comprometido, apenas creian poder llegar a completar 7 u 8. Después de la forma en que todos los habían felicitado por la demo del primer Sprint, los equipos temían lo que podría llegar a ocurrir si sólo terminaba el 33% del compromiso del segundo Sprint. Así, los equipos decidieron que la única forma de entregar todo era dejar de hacer pruebas y refactors; simplemente agregarían la funcionalidad nueva encima de la vieja. Pensaban que luego podrían comprometerse por mucho menos en el tercer Sprint, de forma de tener tiempo de arreglar los problemas.

Uno de los Scrum Masters les preguntó qué estaban haciendo. El Scrum Master sabía que el proceso de Scrum se basa en un progreso empírico y en la transparencia, de manera que el Dueño del Producto siempre pueda saber qué está ocurriendo y tomar así las mejores decisiones. Sin embargo, ¿el equipo no había decidio ocultar cosas al Dueño del Producto? ¿No estaban pretendiendo decir que había cosas hechas, cuando no lo estaban? Los equipos, luego de expresar su miedo de que el Dueño del Producto los despida a todos, fueron al Dueño del Producto y le mostraron el avance real y los problemas que estaban teniendo. El Dueño del Producto los miró y les dijo: "Ya sabía que se habían comprometido por demás. Estaba por preguntarle qué estaba ocurriendo. Esperaba que quizás ustedes sabían algo que se me había escapado. En fin, estoy contento que hayan venido a verme". El Dueño del Producto y el equipo redujeron el compromiso para ajustarlos a la realidad, y poder así seguir sprint a sprint construyendo el sistema.

Miedo a la verdad

Cuando discuto este tipo de temores en los cursos, es muy palpable el miedo que tienen los participantes. Los usuarios que están por adoptar Scrum no piensan que la transparencia o la verdad son aceptables en donde trabajan. Me dicen que los van a despedir si dicen la verdad. La verdad no es lo que los clientes quieren escuchar. Me dicen que sus clientes van a encontrar a alguien más que les mienta si ellos no lo hacen. Vi este comportamiento en todas las clases, durante cinco años. Las personas que trabajan en el desarrollo de productos creen que sus clientes quieren escuchar noticias sólamente cuando son buenas, y que prefieren escuchar una mentira antes que la verdad. "Mentira" es una palabra muy dura. Pero, ¿cómo se dice cuando decimos que algo es cierto, sabiendo que no lo es? ¿De qué otra manera se dice cuando engañamos a alguien con información, o le ocultamos información que podría llevarla a tomar mejores decisiones? Los Dueños del Producto quieren creer en la magia, y los desarrolladores apoyan este comportamiento cuando mienten. "¿Pueden hacer este proyecto para esta fecha?"  "Seguro, no hay problema".

Los desarrolladores son conscientes de las complejidades que provocan cambios en sus estimaciones originales. Saben que el cliente no está contento. Si el cliente se acerca a un Líder de Proyecto al 60% de avance del proyecto y le pregunta cómo va el proyecto, el líder seguramente no tiene idea. Sabe que algunas cosas van bien. Sabe que algunas cosas podrían resultar críticas. Sin embargo, como contestar "No sé" es inaceptable, los líderes de proyecto aprendieron a decir "Todo perfecto", "Va a ser facil terminar", "Llegamos bárbaro", o cualquier otra cosa equivalente que haga que el cliente pueda irse, y el líder se queda con el tema de hacer encajar todo en tiempo, en costo. Básicamente, mienten. Es más facil mentir que exponer todos los problemas y complejidades que llegan al "No sé".

Los líderes de proyecto también creen que mentir les ahorra tiempo. Pero como Scrum se basa en la transparecencia, mentir va en contra del verdadero motivo de Scrum. Si el Dueño del Producto no sabe exactamente cómo estan las cosas en todo momento, no va a poder tomar las mejoras decisiones posibles para lograr sus objetivos. Los Dueños de Producto necesitan la mejor información posible, tanto sea buena como mala.

Basado en The Enterprise and Scrum, por Ken Schwaber.