El problema de los "deadlines"

¿De verdad hace falta que vuelva a poner la web de Renfe como ejemplo de lo que las fechas límites o "deadlines" acaban provocando?

Las fechas topes en un proyecto no es que no motiven, es que destruyen la motivación.

Sin embargo es fácil encontrar a mánagers imponiendo dichas fechas en un desesperado y absurdo intento de vender certeza en medio de la incertidumbre.

En mi última formación comentábamos un ejemplo muy sencillo: "Si me dedico a hacer cucharillas, siempre las hago exactamente iguales, no hay cambios ni en la forma de hacerlo ni en la forma de la cucharilla y en mis 25 años de experiencia sé que siempre hago mil cucharillas al día, si me preguntan cuándo podré entregar cinco mil cucharillas puedo decir con una altísima probabilidad de acierto que lo entregaré en cinco días". ¿Por qué? Porque es un ejemplo de un entorno muy simple y por lo tanto predecible (lo que no significa que no pueda pasar nada en esos cinco días que provoque un retraso, como una enfermedad, por ejemplo).

Sin embargo, en un entorno complicado o complejo donde tenemos que ir ajustando nuestro producto a las necesidades del cliente, donde no hay dos productos iguales, donde la tecnología y/o herramientas a usar van cambiando cada poco tiempo, no tiene sentido tener un "deadline", porque no es posible hacer predicciones sin una evidencia previa.

¿Qué ocurre cuando ponemos una fecha límite a nuestro proyecto en un entorno complejo?

• El miedo a no cumplir el plazo reduce la transparencia.
• No queda espacio para el aprendizaje, lo que paraliza la necesaria evolución del producto.
• El estrés de entregar a tiempo conduce a tomar atajos, eliminando el foco en la calidad.
• Evitar sentirse culpable y señalado por los plazos incumplidos reduce el trabajo en equipo.
• La ansiedad por empezar aumenta el trabajo en progreso y los pasos en falso, y es por tanto el inicio de los retrasos.

¿Y qué pasa cuando lo importante no es la fecha límite?

Simple: Sin estrés por los plazos, los equipos tendrán espacio para llegar al producto correcto, de la manera correcta y en el momento correcto.

¿Entonces por qué al inicio de un proyecto aparece un gerente que nos impone un "deadline"?

1. Porque todos los demás lo hacen así.
2. No conoce toda la verdad.
3. Por miedo a la pereza del equipo.
4. La excepción se ha convertido en regla.
5. Porque su jefe/cliente/stakeholder se lo requiere.

Veamos por qué ocurre y cómo ponerle remedio:

1 - Porque todos los demás lo hacen así.

La presión de grupo por homogeneizar puede logar mantener vivo un mal hábito.

Cuando todos los demás establecen plazos, es fácil alinearse. Y es extremadamente difícil ser quien no se deja llevar por la corriente.

El miedo a ser culpado y señalado por romper con el hábito de los plazos es habitual para todos.

El remedio: Ten el coraje de romper el patrón.

Ésta es la parte difícil.

Cada movimiento exitoso fuera del comportamiento de fecha límite ha requerido un acto de puro coraje. Alguien tenía que tomar una posición.

Es posible que la espera por la seguridad nunca suceda en un entorno basado en plazos.

Decir “no” a los plazos puede resultar convincente viniendo de un ejecutivo. Aquí el movimiento sería contagioso y duradero.

Pero no hay que descartar el poder del coraje en ningún nivel del organigrama. Forma una tribu de promotores, une fuerzas con tu equipo u obtén el apoyo de tu líder.

Todo lo que se necesita es un éxito sin fecha límite para generar impulso hacia un futuro sin fecha límite.

2 - No conoce toda la verdad.

Los gerentes a menudo descubren que están a oscuras, sin ser conscientes de los problemas (debido a los propios perversos ciclos de plazos).

1. Se fijan plazos ("deadlines") para impulsar la urgencia y combatir la incertidumbre.
2. El incumplimiento de dichos plazos genera culpa.
3. La culpa lleva al miedo.
4. El miedo lleva a ocultar el problema.
5. Ocultar el problema conduce a más plazos y hace que el ciclo de culpa se retroalimente.

Los plazos acaban formando una olla a presión en los esfuerzos de productos inciertos, provocando que la transparencia caiga en picado.

El remedio: Acepta la verdad cuando la obtengas.

Rompe el patrón al no culpar.

Cuando la verdad no es lo que quieres escuchar, abraza y celebra el problema. Entonces generarás confianza y le darás a tu equipo valor para plantear problemas de manera oportuna.

Además, y posiblemente más importante, no establezcas plazos falsos sólo por motivar.

3 - Por miedo a la pereza del equipo.

"Pero si no tienen una fecha límite, se equivocarán".

Para algunos gerentes, no tener fecha límite es el camino más rápido para que el equipo se tome el día libre para jugar videojuegos. Para ellos, la ausencia de plazos conduce a un esfuerzo mínimo. Sin embargo, utilizar plazos para motivar es elegir el palo en lugar de la zanahoria.

El remedio: Confía en los profesionales que contrató e inspírales.

¿Estás rodeado de profesionales? Entonces, trátalos como tales. Trabaja con ellos para crear un propósito inspirador y objetivos de producto significativos. Y apóyalos cuando necesiten tu ayuda para superar obstáculos que no pueden eliminar.

Un equipo inspirado y autoorganizado hacia una meta significativa, eclipsa a cualquier equipo que se esfuerza por cumplir con una fecha límite sólo por tenerla.

4 - La excepción se ha convertido en regla.

“Pero existen plazos reales. Piensa en el Black Friday, el día de los impuestos, etc."

Por supuesto que pueden existir limitaciones de fechas legítimas. Pero ese no es el problema. El problema es cuando todo tiene un plazo, independientemente de la necesidad.

Las limitaciones de fechas reales existen, pero son la excepción, no la regla.

El remedio: dejar que los plazos sigan siendo excepciones y evitar que se pongan en riesgo.

Cuando existan limitaciones de fechas reales, implementa contramedidas de reducción de riesgos.

• Inclínate más por la acción que por el plan.
• Experimenta, aprende temprano y con frecuencia.
• Utiliza la evidencia para trazar el mejor y más corto camino hacia su objetivo.
• Encuentra la solución más simple para satisfacer las necesidades de tu usuario y di "No" a lo no sea esencial.
• Concéntrate en terminar una cosa a la vez, no en empezar todo de una vez.

No permitas que la excepción se convierta en la regla, pero sé inteligente cuando sí lo necesites realmente.

5 - Porque su jefe/cliente/stakeholder se lo requiere.

“¿Cuándo estará hecho?”

Dios mío, la temida pregunta. A todos nos han preguntado esto alguna vez. La presión para complacer a nuestros clientes (o jefes) es intensa. Este es tu momento de la verdad como gerente. Y normalmente llega al principio: el momento de mayor incertidumbre.

El camino desafortunado suele ser el de hacer una promesa y fijar un plazo para el equipo. Y a partir de ahí ya todo irá de mal en peor.

El remedio: Invita a quienes soliciten una fecha a unirse al viaje.

No actúes como si tuvieras una bola de cristal.

Sé humilde. Di que no lo sabes con seguridad. En lugar de ofrecer una cita para parecer confiado, invítalos a unirse al equipo a lo largo del viaje.

Tus comentarios proporcionarán el aprendizaje que necesitan para ofrecer lo correcto en el menor tiempo posible.

Scrum como solución.

Como gerente, todos estos puntos los puedes paliar con un buen Scrum Team, con un Product Owner experto y muy empoderado y un gran Scrum Master que os guíe a la organización sobre qué puntos son necesarios y en cuáles se puede mejorar.

Recuerda que nuestro primer objetivo no puede ser nunca entregar en fecha, sino satisfacer al cliente con un producto usable y de valor que responda a sus necesidades actuales. ¿O acaso Renfe consiguió satisfacción cuando publicó su web en fecha?

En el curso de Scrum Master, vemos cómo optimizar tu flujo de trabajo y cómo afrontando los problemas con mucha antelación se facilita conseguir los hitos a corto, medio y largo plazo que nos vayamos proponiendo (los cuales revisaremos y moveremos en cada una de las iteraciones junto con los interesados en nuestro producto).

Esta entrada está basada en el artículo "The Inescapable Deadline: 5 Reasons Managers of Product Teams Keep Setting Them" de Todd Lankford