Una de las mayores críticas que recibe Scrum es la carencia de una documentación exhaustiva, una documentación, que según estos mismos argumentos, ayuda a seguir el plan y a que se cumpla exactamente.

En este aspecto tienen toda la razón, Scrum no esta acompañado de una exhaustiva documentación, como dice uno de los principios del manifiesto ágil: “El software que funciona, por encima de la documentación exhaustiva”.

Scrum no adivina el futuro lejano, ni el intermedio, como mucho te ayuda a tener una visión general de como quiere llegar a ese futuro. Scrum te ayuda a ir dando pasitos hasta llegar a él, pero no sabe que ocurrirá en el futuro .

En realidad nadie sabe que ocurrirá en un futuro lejano, cualquier proyecto que tenga de tiempo de trabajo mas de un año tiene una gran incertidumbre, por lo que querer averiguar el futuro con una documentación exhaustiva, es como jugar a las cartas de tarot, por eso Scrum decide aprovechar el tiempo que se invierte en generar esta documentación en otros menesteres, como por ejemplo comenzar ya el camino, el trabajo, que ya veremos donde estaremos dentro de unos meses.

Lo que es una crítica con argumento, en verdad se convierte en una herramienta que no sirve para predecir el futuro, si no todos seríamos visionarios y sabríamos adivinar el futuro.

Los estudios demuestran que un 64% de las funcionalidades implementadas en proyectos con una documentación exhaustiva no se usan, y que solo un 16% de los proyectos se completa con éxito. Estas cifras demuestran que la disposición de una documentación grande no garantiza adivinar mejor el futuro.

La recomendación es preparar de forma sencilla una hoja de ruta con las ideas básicas que se quieren alcanzar priorizadas por importancia y comenzar a caminar. Cuando se vayan cumpliendo etapas ya se volverá a pensar sobre nuevas necesidades e incluso añadir la documentación necesaria para su buena ejecución si hace falta.

Esta semana en la web de Proyectalis, han puesto a disposición de toda la comunidad la traducción al español del libro “Kanban and Scrum – making the most of both“, escrito por Henrik Kniberg & Mattias Skarin y prologado por Mary Poppendieck & David Anderson.

Descarga del libro en español desde la web de Proyectalis.

Para descargar la versión en Inglés, se debe acceder a la web de InfoQ.

Han participado en esta traducción el equipo de agile-spain.com
Rodrigo Corral, Xavier Quesada-Allue, Jorge Uriarte, Agustín Yagüe, Teo Sánchez, Juan Palacio, Gregorio Mena, Ángel Agueda, Laura Morillo-Velarde, Jorge Jiménez, Javier Sánchez  y Juan Quijano.

Coordinación de la traducción: Ángel Medinilla.

Uno de los errores mas comunes que se comete a la hora de implementar Scrum en un equipo de trabajo, es estimar el coste de los esfuerzos en horas. Nunca se debe utilizar este parámetro, dado que el factor tiempo solo es una parte de la ecuación.

Cuando una persona pregunta como se cuantifica en valor de 1 esfuerzo en Scrum, lo ideal es plantear la siguiente ecuación:

Esfuerzo = Tiempo + Incertidumbre + Complejidad

Un claro ejemplo exagerado de que no solo se puede medir en tiempo los esfuerzos de cada tarea de la pila de producto es el siguiente:

Una médico tiene que operar de apendicitis a un paciente, a lo mejor lo hace en 20 minutos, pero necesita tener todos sus sentidos alertas para no fallar, se está jugando la vida de una persona. La tarea en tiempo no es mucha, la incertidumbre de lo que se va a encontrar tampoco, pero la complejidad de las acciones que va a llevar a cabo es alta, lo ha tenido que aprender en muchos años de estudio y prácticas.

Después de esos 20 minutos de alta concentración. El médico debe descansar y tomar una pausa para pasar a su próxima tarea.

Con esto queremos hacer reflejar que el tiempo solo es uno de los factores de la ecuación del cálculo de un esfuerzo, cuando un equipo se reúne para estimar una pila de producto, no puede tener este valor solo como referencia, porque entonces la operación de apendicitis costaría casi “0 puntos”.

Volvemos a hablar de ScrumManager, y esta vez para recomendar sus podcats, dado que son unas lecciones muy interesantes. En cada uno se van tratando diversos temas, siempre relacionados con Metodologías Ágiles y Scrum.

Lo podcats son un coloquio entre personas invitadas debatiendo sobre el tema principal. El nivel de los participantes es muy alto, entre ellos: Agustín Villena, David Alfaro,etc.

Recomendamos esta página, por que cada vez es mas completa, puedes realizar cursos, acceder a mucha información y escuchar podcast.Los podcast te permiten poder escucharlo en cualquier momento y circunstancia, lo que nos permite aprovechar cualquier momento de viaje o de espera para seguir formándonos en Scrum y las Metodologías Ágiles.

Volvemos a emplear una imagen del genial Forges para ilustrar este tema.

Antes que nada explicar que se le llama “Deuda Técnica” a una metáfora creada por Ward Cunningham:

Aquella deuda que se contrae, normalmente con los clientes que no con los bancos, aunque si un banco es tu cliente es posible que tengas una deuda técnica con él, cuando se decide hacer las cosas de forma rápida, normalmente interrumpiendo la pila de sprint.
Esta interrupción u distorsión suele tener como objetivo meter mas carga de trabajo en la pila de sprint, o también, acelerar artificialmente la velocidad para poder llegar a una fecha de entrega pactada, por lo que el resultado final de esta entrega no cumple con los estándares de calidad admisibles, comprometiendo además los futuros desarrollos con el mismo cliente.
Se genera una “Deuda Técnica” con el cliente, que genera unos intereses futuros, la cual se arrastrará en siguientes trabajos hasta que no se le ponga una solución.

El foco de inicio de la deuda suele venir por la prisas el Product Owner, que presionado por el cliente decide alterar los sprint para poder cumplir objetivos.
Todos los clientes sienten una tentación a denominar urgente a muchos encargos, aunque de verdad no tengan esta etiqueta. Este mensaje se lo transmiten al Product Owner, y al final repercute en la velocidad y la calidad.

Para poder minimizar los efectos de las deudas se pueden plantear varias soluciones:

  • Explicar al cliente las consecuencias de sus decisiones, las cuales van a generar una deuda técnica, y que en un futuro se deberá disponer un tiempo para arreglarla.
  • Demostrar con un ejemplo práctico al cliente que la deuda disminuye la calidad del resultado.
  • Enseñar al Product Owner a decir “No”.

- Un ejemplo práctico real de deuda técnica en un desarrollo de un software:

Un cliente tiene la necesidad de presentar una página web en una fecha en concreto, el equipo de producción eran dos personas, por lo que disponía solo del tiempo de esta dos personas.

Estaban realizando el proyecto según el plan previsto, pero el cliente al final necesitó lanzar la página antes de lo previsto, por lo que modificó algunas tareas. Para ello decidió crear una plantilla única para todos los contenidos de texto de los artículos, los cuales solo incluían una foto al comienzo de cada artículo y un texto, así ahorraba tiempo en el diseño y la maquetación de la web.

A la hora de lanzar la web se dió cuenta de que la mayoría de artículos deberían tener mas de una foto, había asumido una deuda técnica por salir antes, y ahora venían las consecuencias por las prisas, o pagaba por las próximas horas para volver a programar el gestor de contenidos o se quedaba como estaba.

En muchos proyectos no es tan clara la deuda técnica, pero son pequeños detalles que se van sumando, y al final del mismo suponen un gran problema.