Hablemos de Deuda Técnica - El mal que puede acabar tu proyecto-producto ágil - Reloaded

Hablemos de Deuda Técnica - El mal que puede acabar tu proyecto-producto ágil - Reloaded from Jorge Hernán Abad Londoño

Bad Smells in Agile Transformations

Bad Smells in Agile Transformations de Jorge Hernán Abad Londoño

Un Horrendo y Horroroso Scrum

Hola a todos

Reciente pasamos el Hallowen y quisiera compartir algo que me asusta de muchas implementaciones y adopciones de Scrum.

Comencemos

Durante mucho tiempo en mis entrenamientos de Fundamentos de Scrum comparto el siguiente texto de Tobias Mayer (https://agileanarchy.wordpress.com/scrum-a-new-way-of-thinking/) con los asistentes:

"Imaginen si nuestros días en el trabajo estuviesen llenos de sonrisas y sentimientos de compañerismo y llenos de emoción. Imaginen un espacio de trabajo que se remontan a patios de la infancia, donde la invención  y la innovación eran una parte natural de cada interacción. Imaginen que es responsable de su propio entorno, su propio ritmo y su propia carga de trabajo.  E imaginen entregar con frecuencia un trabajo de calidad con  a unos clientes encantados y relajados. Se puede convertir esa imaginación en realidad. Existe un mecanismo simple y bien entendido para ir desde donde estás ahora a donde le gustaría estar, y no, ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes." Tobias Mayer

Y la verdad cuando lo comenzamos a leerlo, todos creemos que vamos a terminar diciendo "sí, si es Scrum, es la bala de plata que siempre habías buscado y que va a solucionar todos tus problemas" y el texto termina muy clara y contundentemente "ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes."

Y somos nosotros y no el framework los encargados de cambiar nuestra forma de trabajo, el framework ayuda, pero podemos aún teniendo Scrum como forma de trabajo situaciones que dan espanto:

• Product Owners o Scrum Masters que son los jefes de los equipos y los presionan y exprimen y los tratan como "recursos"
• Scrum Master que solo se preocupan de agendar reuniones y no se ocupan de la mejora continua de su equipo, ni de su PO
• Equipos en los que no se entienden (para ser sincero, realmente no son equipos)
• Equipos con deuda técnica creciente y sin herramientas adecuadas
• Equipos que no tienen buenas herramientas y no están orientados a la excelencia técnica
• Equipos con muchos sprints encima y sin salir a producción
• Equipos sin retrospectivas
• Equipos con dailys de seguimiento estricto y no de sincronización
• Equipos Scrum donde se gestionan las horas y las estimaciones y en los que "toca reponer el tiempo si se falla una estimación"
• Equipos Scrum trabajando bajo un contrato de alcance fijo, tiempo fijo y costo fijo (todo fijo)
• Metricas de cascada aplicadas a proyectos ágiles
• Product Backlog al cual se le hacen frecuentes controles de cambio
• Planning asignadas previamente por el PO (y posiblemente un líder técnico)  y no estimadas por el equipo
• y muchas más

Lo anterior muy coincidente con la frase de Ken Schawber

“En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura.(1) ” Ken Schawber

Da pavor ver estas situaciones, y es nuestra labor como Scrum Masters como Agile Coaches trabajar con la organización y los equipos para generar entornos de trabajo diferentes, y cierro como dice Tobias "ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes." 

Bienvenido el feedback, los comentarios y las historias de terror.

Saludos Ágiles

Jorge Abad

Notas

1. Creo que Ken hubiera querido terminar esta frase con una palabra más contundente

[Scrum] Ritmo Sostenible sobre Ritmo Insostenible

Metrónomo: utilizado para indicar tiempo o compás de las composiciones musicales. Produce regularmente una señal, visual y/o acústica, que permite a un músico mantener un pulso constante al ejecutar una obra musical.(1).

Hola a todos:

He escuchado algunas veces decir esta expresión a los Scrum Masters o Product Owners:

"Equipo TENEMOS QUE DARLE A MORIR para que entreguemos todo lo comprometido en este sprint"

[BadSmell-1: Se impone al equipo el sobre-esfuerzo](2)

Desde el punto de vista de Scrum y Agile se ven varios problemas en esta frase.

1. En Scrum los equipos trabajan en hacer la MAYOR y MEJOR cantidad de alcance (o ítems de backlog) que solicite el PO durante la jornada laboral, ni más ni menos.
2. Es posible que durante el sprint se complete o no todo lo propuesto durante el planning, en caso de que se termine antes se solicitará más ítemes, en caso de que no se complete lo planeado se emplea el timebox para identificar en la retrospectiva por qué no se logro lo planteado y las acciones a realizar en el siguiente ciclo.
3. (se que el comentario que sigue le dolerá a los amigos del control) En Scrum los equipos son los que deciden si sobre-esfuerzan o no - ojo, es importante no caer en el otro extremo y creer Scrum significa ser anárquicos, y no cumplir jornada laboral etc, recomiendo estos dos post acerca del tema (7)(8)-,es normal que planteemos el sobre-esfuerzo pero debe ser una decisión de equipo no una imposición, y como principio clave se debe compartir el propósito de este sobre-esfuerzo para comprender la causa y la necesidad del mismo.

Pero no todo termina allí

El problema radica en que la frase del "DARLE A MORIR" no es solo de un sprint, sino que es frecuentemente usada todos los sprints, y allí con seguridad emerge [BadSmell-2] que ni la organización, ni el Product Owner, ni el Scrum Master entienden mucho de Scrum, ni de Ágil, y estan llevando las prácticas de la gestión tradicional al contexto ágil, y pronto veremos al equipo decir:

• "no ganamos nada con Scrum"
• "pensábamos que íbamos a mejorar nuestra forma de trabajo y nuestra vida, y no es cierto"
• "esto no fue lo que nos dijeron en el entrenamiento"
• "antes -en cascada- solo nos esforzábamos al final, ahora cada dos semanas tenemos una semana de martirio"

Lo anterior denota que se olvida el principio ágil de:

"Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida." (3)

Y no estoy afirmando que esporádicamente o muy ocasionalmente no existirá algún sobre-esfuerzo(4) -realmente a veces se requiere- pero es importante comprender que los equipos necesitan cierta cadencia o ritmo para navegar con cierta comodidad - o cuasipredictibilidad - en el mar de la incertidumbre(5).

Por lo tanto este sobre-esforzar al equipo constantemente es indicador de:

1. [BadSmell-3] El Scrum Master no esta empleando la retrospectiva como instrumento para entender por qué el desgaste constante del equipo y como salir de este círculo vicioso.
2. [BadSmell-4] El Product Owner cree que puede pedir y exigir todo lo que quiere sin considerar la capacidad del equipo.
3. [BadSmell-5] El equipo no es protegido por el Scrum Master de las malas prácticas
4. [BadSmell-6] El equipo aun no es consciente de su autoorganización y de su capacidad de decir "NO" ante esta mala práctica continuada

Adicionalmente este sobre-esfuerzo frecuente llevará al desgaste del equipo y con seguridad a la desintegración del mismo o renuncia de alguno o varios de sus miembros (6).

Espero con esto haber aclarado un poco sobre este BadSmell en las organizaciones que comienzan con Scrum o aun no saben como trabajar con el.

Hasta la próxima.

Saludos ágiles
Jorge Abad.

Referencias, Aclaraciones, Comentarios y Notas

1. Ver definición de Metrónomo en Wikipedia - clic aquí.
2. Usaré la etiqueta BadSmell para resaltar lo que son malas prácticas
3. Ver los principios -aquí-.
4. Un post sobre el sobre-esfuerzo que escribí hace un muy buen tiempo - clic aquí -.
5. Principios de Incertidumbre de Requisitos, Procesos y Productos de Software - clic aquí-.
6. Dice Sun Tzu en el arte de la guerra: "Las armas son instrumentos de mala suerte; emplearlas por mucho tiempo producirá calamidades. Como se ha dicho:"Los que a hierro matan, a hierro mueren." Cuando tus tropas están desanimadas, tu espada embotada, agotadas tus fuerzas y tus suministros son escasos, hasta los tuyos se aprovecharán de tu debilidad para sublevarse. Entonces,aunque tengas consejeros sabios,al final no podrás hacer que las cosas salgan bien."
7. ¿Que significa autoorganización en Scrum? (Clic aquí)
8. Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado (Clic aquí)