Scrum: Anti Patrones

Introducción
Los antipatrones en Scrum
Scrum es uno de los marcos de trabajo más utilizados en el mundo para organizar equipos
y proyectos. Posiblemente, ya tengas conocimientos sobre Scrum o trabajes en una
organización que lo aplica en tu proyecto y te ha tocado experimentar problemas donde
aparentemente Scrum se queda corto, o, peor aún, aparecen problemas generados
precisamente por usar Scrum. Soy Carlos Solís, autor, instructor y Scrum Master
certificado. En este curso vamos a explorar el lado oscuro de Scrum y descubriremos sus
problemas y errores comunes de implementación. Te mostraré herramientas para
detectar antipatrones y técnicas para adaptarse y comenzar a corregir el rumbo. Al
terminar este curso, dominarás el concepto de antipatrón y conocerás cómo prevenirlos
antes de que se vuelvan un problema en tu proyecto.

Scrum en el mundo ideal

Qué es Scrum y qué promete
Scrum es, en pocas palabras, un marco de trabajo para gestionar proyectos complejos. Se
utiliza en todo tipo de empresas y organizaciones para desarrollar y mejorar una muy
amplia gama de productos y servicios. Scrum se ha convertido en el estándar de facto de
muchas industrias y, por su flexibilidad y facilidad de uso, se aplica desde
emprendimientos con solo un puñado de miembros hasta corporaciones con operaciones
multinacionales y miles de empleados. Parte de la popularidad de Scrum se debe a que es
económico y sencillo comenzar a usarlo. No necesita ningún software, licencias o
infraestructura, por lo que se adapta a cualquier presupuesto y a organizaciones de
cualquier tamaño. Los proyectos usan Scrum por un sinnúmero de razones, pero entre las
principales tenemos: clientes satisfechos, un mejor retorno de la inversión, reducción de
costos, resultados rápidos y confianza en los procesos. Y todo esto es cierto, me ha tocado
experimentar muchas implementaciones de Scrum: algunas muy buenas, otras no tanto. Y
cuando todo funciona bien, el producto avanza. Y nada hace más feliz a un cliente que
tener resultados o, mejor aún, ver que su producto está terminado a tiempo. Al usar ciclos
cortos y un avance basado en pequeñas iteraciones, Scrum se asegura de reducir el riesgo
disminuyendo los costos de desarrollo, mientras que usa un sistema de mejora y
adaptación continua para que la frecuencia de los posibles errores se reduzca al máximo
posible. Estos ciclos cortos no solo reducen costos, también permiten ver resultados
tangibles desde la primera iteración. Uno de los principios de Scrum es entregar un
producto totalmente funcional y listo para usar al final de cada ciclo, lo que significa que
en poco tiempo el cliente tiene un producto potencialmente entregable con el que
comenzar a reclutar usuarios o conseguir financiamiento. Al crear un sistema que procesa
todos los requerimientos y los subdivide en tareas más pequeñas y simples, Scrum genera
un avance constante, eficiente y manejable que poco a poco logra conquistar cualquier
proyecto sin importar lo difícil que pueda ser. En vez de tratar de pasar la montaña en un
solo salto, Scrum propone atravesarla con pequeños pasos, lento pero seguro. Scrum y sus
procesos son fáciles de entender y comenzar a utilizar. Cualquiera puede entender
rápidamente la dinámica de las reuniones y roles. Pero que sea fácil de adaptar y entender
no significa que tienes garantía de que todo va a funcionar milagrosamente. Scrum trabaja
con personas y las personas somos complejas. Dominar Scrum es un proceso que toma
tiempo y requiere mucha experiencia para aprender las sutilezas e interpretaciones del
proceso.

Rituales y administración de equipos en Scrum

En Scrum se maneja el concepto de rituales para designar algunos procesos cíclicos que
involucran al equipo. Cada ritual es una reunión cara a cara que aleja por un momento a
los miembros del equipo del trabajo que están haciendo y les ofrece la oportunidad de
tener una comunicación abierta entre ellos para aumentar el contexto de su trabajo.
Scrum favorece la comunicación por encima de la documentación, por lo que proporciona
oportunidades regulares y claramente definidas para varios tipos de comunicación, útil y
significativa. A diferencia de la reunión habitual, cada ritual de Scrum tiene un objetivo
específico y claramente definido. Tiene un rango de tiempo máximo dentro del cual los
presentes deben obtener resultados. Todos los que asisten a un ritual saben antes de que
comience lo que deben esperar, cómo deben comportarse y cuál debe ser el resultado
final. Scrum tiene cuatro rituales, comisiones, público y duración, claramente definidas, y
estos son el Scrum diario, la planificación del Sprint, la revisión del Sprint y la
retrospectiva. El Scrum diario, como su nombre lo sugiere, es una reunión que se realiza
todos los días entre todos los miembros del proyecto para discutir su estatus actual. El
Scrum diario sincroniza al equipo sobre el avance y estado actual del proyecto, genera
visibilidad sobre los avances y potenciales obstáculos y en muchas ocasiones le da un
mapa rápido al equipo de lo que ocurrirá durante el día. Otros de los rituales es la
planificación del Sprint, que es el momento en que se delimita cuál será el plan de acción
del equipo en la siguiente iteración del proyecto. La planificación del Sprint es una reunión
donde los miembros del proyecto deciden participar activamente y tiene una duración de
aproximadamente dos horas por semana de duración del Sprint. Por ejemplo, en un Sprint
de dos semanas el límite sería de cuatro horas. El siguiente ritual del que te voy a hablar
es la reunión del Sprint, que es el más informal de todos los rituales y tiene como objetivo
experimentar el avance realizado durante la última iteración. En la revisión del Sprint se
hace una demostración del proyecto probando en un entorno realista e integrado todas
las novedades del producto. Por último, tenemos la retrospectiva, uno de los rituales más
importantes de Scrum en el cual los miembros del equipo se juntan para analizar los
resultados, evaluarse a sí mismos y principalmente buscar formas de mejorar. Estos cuatro
rituales en conjunto mantienen al equipo comunicado y organizado a lo largo del ciclo de
trabajo.

Planificación y artefactos en Scrum

Todo proyecto necesita tener una ruta clara, un mapa que le indique adonde dirigirse. En
Scrum tenemos elementos que nos permiten planificar y definir la ruta hacia la cual
enfocar nuestros esfuerzos durante cada Sprint. Estos objetos son llamados "artefactos".
En Scrum, un artefacto es un documento creado para guiar o inspirar al equipo en
diferentes momentos del desarrollo del producto. Scrum describe tres artefactos
primarios que son la bitácora del producto, la bitácora de Sprint y el incremento. El
primero, y posiblemente el más importante de los tres, es la bitácora de producto, un
documento generado y administrado por el dueño del producto, que es la persona
encargada de aportar la visión sobre lo que se espera de este producto. El dueño del
producto va creando registros dentro de la bitácora. Estos registros contienen ideas y
funcionalidades que considera relevante para el usuario. Los registros deben incluir
detalles de la funcionalidad deseada y estar redactados desde el punto de vista del
usuario, porque es la persona que va a utilizarlos y el producto siempre debe estar
enfocado en crear una experiencia que aporte un valor agregado a este usuario. Por el
enfoque que tienen estos registros es que reciben el nombre de "historias de usuario", y la
bitácora de producto puede tener una cantidad indefinida de estas historias, que pueden
ir desde lo concreto hasta elementos que aún no están en capacidad de realizarse. Al
iniciar un Sprint, el dueño del producto se reúne con el resto del equipo y en conjunto
eligen cuáles van a ser las historias de usuario que se implementarán en la iteración
actual. Para eso, el dueño del producto previamente a esta reunión debe preparar las
historias de usuario de la bitácora, priorizarlas según la importancia que considere
adecuada. Esta jerarquización es un proceso exclusivo del dueño del producto y ningún
otro rol puede cuestionarlo. Luego se procede a discutir con el equipo cuáles y cuántas
historias pueden ser implementadas y aquí se debe crear otro artefacto llamado la
bitácora de Sprint. Este documento es similar a la bitácora de producto pero que contiene
únicamente las tareas que se van a realizar dentro del Sprint actual. Podemos ver este
artefacto como la promesa que hace el equipo sobre el avance que va a realizar durante el
siguiente Sprint. Finalmente, al terminar el Sprint y cuando el equipo ha terminado de
implementar todas las tareas, se toman los contenidos que se encuentran en la bitácora
del Sprint y todos aquellos que hayan terminado efectivamente pasan a un nuevo
artefacto llamado el incremento. Este último artefacto contiene únicamente las áreas que
están debidamente implementadas y sirve como un documento histórico y de referencia
para examinar cuáles son las funcionalidades que posee actualmente el producto. Los tres
artefactos en conjunto nos dan una visión completa de lo que se espera que sea el
producto, el compromiso actual de trabajo y todos los elementos que ya fueron
implementados.
Flujo de trabajo en Scrum
Scrum tiene un flujo de trabajo característico y es posible que sea uno de los elementos
por lo que es más conocido. Este flujo de trabajo está diseñado para mantener a los
miembros del equipo enfocados en la creación de soluciones y resolución de problemas,
generar procesos de constante adaptación y mejora que les permitan evolucionar y
madurar como equipo al mismo tiempo que mantienen atención a la planificación del
proyecto para cumplir con las metas definidas y a tiempo. antes de entrar en detalles
sobre el flujo de trabajo que podemos esperar dentro del equipo que utilice Scrum,
tenemos que hablar del bloque fundamental de tiempo por el que se rigen estos
proyectos. Este bloque de tiempo se llama "Sprint". El Sprint tiene una duración que
puede ir de las dos a las cuatro semanas, dependiendo de las condiciones del producto y
la retroalimentación del equipo. Cada Sprint está seguido inmediatamente de otro hasta
que el proyecto finaliza y las actividades del equipo se realizan en el marco de este ciclo de
tiempo. Sabiendo esto, pasemos a examinar cuáles serían las actividades de trabajo en
Scrum basados en el ciclo de vida de un Sprint. Al momento de iniciar un Sprint, ya
tenemos una lista de tareas esperando para comenzar a trabajar. Las tareas provienen de
la bitácora de Sprint y fueron elaboradas previamente. Seguidamente, los desarrolladores
comienzan a trabajar sobre las tareas detalladas en la bitácora de Sprint y cada día se
reúnen en el Scrum diario para sincronizarse, enterarse del avance el proyecto y detectar
cualquier riesgo o bloqueo que pueda afectar a la producción. Este proceso de avance se
repite durante todos los días hasta finalizar el Sprint. Unos días antes de que esto ocurra,
el equipo se reúne para realizar la planificación del siguiente Sprint. De esta forma,
cuando comience el nuevo ciclo, tendrán todo preparado para comenzar a trabajar
inmediatamente. Una vez finalizado el Sprint, el equipo asiste a una reunión donde se
examina el avance realizado y se exploran todas las nuevas capacidades. Todas las tareas
aprobadas pasan a formar parte del incremento, que es la bitácora donde almacenamos
todas las tareas ya implementadas. El ciclo de trabajo finaliza con una retrospectiva donde
todos los miembros del equipo reflexionan sobre las cosas que salieron bien, las que
salieron mal y, en especial, buscar en conjunto cómo mejorar y cómo evitar que esos
errores vuelvan a ocurrir. La retrospectiva finaliza oficialmente el Sprint de Scrum y al día
siguiente comienza inmediatamente un nuevo ciclo que repite todas esas mismas
acciones, rituales y procesos. El flujo de Scrum está diseñado para que podamos tomar
una tarea muy compleja y extensa, como la que se encuentra dentro de la bitácora del
producto, la separemos en pequeños bloques, el cual trabajaremos dentro del Sprint, y
todo el avance será agregado finalmente al terminar cada iteración, no sin antes tratar de
aprender todo lo posible para adaptarse y evolucionar. De esta forma es que Scrum no
solo puede descomponer un problema particularmente complejo, sino que también en el
proceso genera un aprendizaje, una evolución y adaptación para que el equipo que
comienza el proyecto evolucione con él y al terminar posea mucho más conocimiento y
experiencia.
Entrega de producto terminado con Scrum
Uno de los objetivos principales de Scrum es que al final de cada ciclo el equipo logre
producir un software completamente funcional y listo para ser utilizado por los usuarios.
Por supuesto que luego de dos o cuatro semanas de trabajo no podemos tener un
producto particularmente sofisticado. El objetivo de todo esto es generar un mínimo
producto viable y comenzar a trabajar con él. Un mínimo producto viable es una versión
reducida o limitada de nuestro producto final. Por ejemplo, si nuestro producto es una
aplicación donde las personas pueden hacer compras del supermercado y recibirlas en
casa, en vez de colocar un extenso catálogo y proveedores, puede comenzar teniendo un
número limitado de productos y entregas en alguna zona específica de la ciudad. Así el
producto existe en su forma mínima y puede comenzar una etapa de pruebas. Es
importante no confundir un mínimo producto viable con un producto incompleto. El
primero tiene todos los elementos necesarios para funcionar, sin embargo, se encuentra
al mínimo posible. El segundo sacrifica funcionalidades clave. Los ciclos cortos de Scrum
permiten que luego de lanzado el mínimo producto viable, un par de semanas después
tendremos una nueva actualización llena de novedades y de funcionalidades que van a
continuar completando y evolucionando este producto. Esta técnica de tener un producto
completamente funcional nos permite comenzar a distribuir el producto desde etapas
tempranas. Esto tiene múltiples beneficios para el cliente. Por ejemplo, puede comenzar a
cultivar sus primeros usuarios mucho antes de tener el producto finalizado. Esto es
particularmente útil para aplicaciones que de alguna forma tienen un contexto social,
porque al momento de finalizar el producto ya poseen una masa crítica. Piensen en
aplicaciones como Twitter, Foursquare o Tinder, sin una base de usuarios no tiene sentido
usarlos. Este tipo de aplicaciones necesita cultivar una base de usuarios incluso antes de
arrancar oficialmente para que el producto tenga sentido. Otro aporte importante que
tienen estos ciclos cortos de entrega es que permiten comenzar a escuchar a sus usuarios
finales desde etapas tempranas, y esto es un elemento clave incorporado dentro del ADN
de Scrum: obtener retroalimentación y adaptarse para mejorar. Pensemos, por ejemplo,
en una aplicación donde tenemos un servicio de comercio electrónico para distribuir
comida rápida. Justo después del lanzamiento comenzamos a recibir sugerencias de los
usuarios y ahí nos enteramos de que quisieran conocer la información nutricional de los
productos que ordenan. Esta funcionalidad no hubiera sido incluida en la versión original
porque en la visión que tenía el dueño del producto esto no era relevante. Pero al conocer
que para sus usuarios sí lo es, tiene una nueva motivación para incluirlo, lo que nos lleva a
otro beneficio de los ciclos cortos de Scrum y es el tiempo rápido de respuesta. Siguiendo
con el ejemplo anterior, esta nueva funcionalidad está a tan solo unas dos o cuatro
semanas de estar implementado en la aplicación, respondiendo a los intereses de los
usuarios en muy poco tiempo. Esto permite que nuestra aplicación sea flexible, adaptable
y que, gracias a la capacidad que tiene de responder a la necesidad del usuario, genere
altos niveles de satisfacción y fidelización.
Los problemas de Scrum
Problema 1: Scrum es demasiado estático
Aunque Agile y, por extensión, Scrum han cambiado para siempre la forma en que se
administran proyectos complejos y equipos multidisciplinarios, como todas las cosas que
creamos los humanos, son imperfectas. No existe ninguna técnica ni ningún marco de
trabajo que sea perfecto o que funcione a la perfección en absolutamente todas las
condiciones. Esto aplica también para Scrum, que, aunque es muy popular, también ha
cultivado detractores. Una de las críticas que se le hace comúnmente a Scrum es que es
poco flexible. Esto viene a raíz de que el sistema de Sprints está diseñado para que, una
vez que arranca, el cliente no pueda hacer ningún tipo de cambio en los requerimientos ni
tampoco agregar o eliminar tareas fuera de las que ya se acordaron con el equipo.
Muchos clientes consideran que esto es una desventaja de Scrum, porque sienten que no
les da la flexibilidad y que a veces temas urgentes no pueden ser implementados cuando
ellos realmente los necesitan. Pensemos en esta situación: estamos desarrollando una
aplicación donde tenemos un mercado común donde los usuarios pueden comprar y
vender sus bienes de segunda mano. Supongamos que estamos trabajando con Scrum y
dentro de este Sprint el equipo de desarrollo y el dueño del producto acordaron que se
iba a implementar una nueva funcionalidad para asignar reseñas y calificaciones a los
vendedores y así identificar cuáles son los vendedores más confiables de la aplicación. Una
vez que el equipo comienza a trabajar en los pormenores de esta nueva funcionalidad, el
dueño del producto recibe una llamada de la junta directiva donde le anuncian que se está
planeando lanzar una promoción dentro del servicio la siguiente semana y les gustaría
incluir una sección adicional que destaque los diferentes productos en promoción. El
dueño del producto contacta al equipo y hace una reunión extraordinaria para
comunicarles que desea incorporar este cambio. Pero, muy posiblemente, el Scrum
Master le informe de que no será posible de realizar porque no es parte de lo acordado
para desarrollar durante este Sprint. Lo más probable es que el cliente se frustre y sienta
que Scrum es una metodología estática que no le ofrece lo que espera y que muy
posiblemente un desarrollador "freelancer" no tendría problema para adaptarse a este
tipo de necesidades. Y es cierto, Scrum en un caso como este puede ser estático e
inflexible. Sin embargo, esto ocurre por diseño y es parte de los múltiples controles para
evitar el caos en un proyecto. Scrum está diseñado para resolver problemas complejos y
no se adapta muy bien a proyectos muy pequeños, en particular cuando son proyectos
simples que se pueden desarrollar en una o dos iteraciones. Scrum está pensado para
proyectos de mediano y largo plazo que necesiten evolucionar y madurar sus ideas a
través de procesos de iteraciones. Asimismo, el concepto de manejar una bitácora Sprint
busca que los desarrolladores tengan tiempo de trabajar con calma y enfocados en sus
tareas, asegurando la calidad y la integridad del código. La bitácora del Sprint, una vez que
inicia el proceso, no está sujeta a cambios precisamente para que los desarrolladores
tengan un panorama estable y puedan desarrollar planificándose a un tiempo definido. Si
agregamos tareas arbitrariamente, esto no solo cambia el alcance de la iteración, sino que
también puede generar un fuerte impacto en la posible carga de trabajo de los
desarrolladores. En otras palabras: si agregamos y quitamos tareas, es posible que
terminemos trabajando el doble o el triple de lo que originalmente se acordó. Esto
significa que los desarrolladores tendrán una carga de trabajo adicional acompañada del
desgaste correspondiente, y, además de todo, el equipo no va a poder cumplir con las
expectativas. Un auténtico efecto dominó. La solución para estos casos es justamente
tener conciencia de que Scrum no tiene un tiempo de reacción inmediata para este tipo
de nuevas tareas y debemos planificarlas como uno o varios Sprints de anticipación. Me
ha tocado trabajar en equipos con proyectos donde tenemos dos y hasta tres Sprints
planificados con antelación para evitar este tipo de sorpresas.

Problema 2: Sprint tiene un enfoque de corto plazo

En Scrum, la vida comienza y termina en un Sprint. Durante ese periodo de dos a cuatro
semanas, los equipos se dedican por completo a los temas y tareas que fueron
seleccionados para trabajar. Aunque un par de semanas puede sonar como mucho
tiempo, realmente el flujo de trabajo tiende a ser intenso. Durante la jornada laboral, un
desarrollador tiene que enfocarse al máximo y evitar distraerse para cumplir con todos los
objetivos acordados a tiempo. Precisamente por esa razón es que debe enfocarse
únicamente en los temas en los que está trabajando. Quiero decir con esto que no pueden
trabajar en ningún tema paralelo a lo que están trabajando. Pongamos un ejemplo: si
estamos trabajando en una aplicación donde tenemos un mercado de compra y venta de
artículos usados y justamente en esta iteración se está implementando un carrito de
compra, mientras un desarrollador está trabajando en ello encuentra un fallo importante
en la arquitectura, pero este error no está relacionado del todo con el tema del carrito de
compra. En este caso, el desarrollador simplemente debe reportar el problema y esperar a
que se genere un ticket de error o una historia de usuario, dependiendo del tipo de
problemas que encontró. Y de ninguna forma debe dedicar más tiempo a ese problema.
Su misión es mantener el foco en la tarea original, que es el carrito de compra. En casos
así, los desarrolladores están atrapados en una mentalidad de corto plazo. Solamente
pueden trabajar en tareas que van a ser resueltas dentro del alcance de la iteración actual.
Sin embargo, esto no es necesariamente malo. Al enfocarse en su tarea, el desarrollador
puede mantener en movimiento la producción y cumplir con los objetivos del Sprint. Un
desarrollar concentrado en un solo tema puede desarrollar un mejor código y así evitar el
re trabajo, lo que libera espacio para ir solucionando más tareas y abarcando
eventualmente el alcance completo del corto y largo plazo.

Problema 3: hay demasiada presión sobre los desarrolladores

Si has trabajado como desarrollador en un equipo de Scrum, posiblemente puedas
identificarte con este escenario. Faltan solo unos días para terminar la iteración y aún
quedan más historias de las que quisieras por hacer. Conforme se acerca el final del
Sprint, notas que a un ritmo normal es muy posible que no logres terminar a tiempo y te
preocupa que el equipo entero sufra una disminución en la velocidad general y eso
significaría que las proyecciones para finalizar el proyecto se atrasen. Fallar en Scrum
puede tener consecuencias importantes. En particular, en los equipos más pequeños,
donde el rendimiento de cada miembro del equipo genera mucho más ruido del usual.
Esta presión generalmente desemboca en que el equipo, o al menos algunos de sus
miembros, terminen trabajando tiempo adicional para poder sacar la producción a tiempo
y mantener las métricas a flote. Justamente esta es una de las principales críticas que se le
hace a Scrum. Si bien es cierto, por un lado, empodera a los desarrolladores para que sean
ellos quienes eligen la carga de trabajo y las tareas que consideran alcanzables dentro de
un Sprint. Por el otro lado, viene acompañado de una trampa y esta trampa es que si tú
mismo elegiste la carga de trabajo que querías tener, ¿cómo puede ser que no cumplas
con eso? No significa que los desarrolladores necesariamente estén perdiendo el tiempo o
que no sean eficientes, en muchos casos los atrasos no están en manos de los
desarrolladores: por ejemplo, cuando aparecen bloqueos externos que no les permiten
terminar su tarea, pero también en la gran mayoría de los casos ocurre que, al momento
de acordar realizar una tarea, siempre hay una incertidumbre de por medio. Por eso es
que los desarrolladores generan estimaciones de sus tareas. Estas estimaciones son
relativas y se calculan a partir del nivel de dificultad que los desarrolladores encuentran al
momento de conocer la historia o tarea. Sin embargo, el nivel de complejidad puede
aumentar al momento de comenzar a examinar en detalle el código o interactuar con sus
diferentes dependencias y generar atrasos que pueden afectar todo el equipo. Para evitar
este tipo de problemas, lo mejor que podemos hacer es dedicar bastante tiempo a cada
historia y durante la reunión de planificación evacuar todas las posibles dudas. Un
ejercicio bastante útil es que, antes de estimar, los miembros del equipo involucrados con
la tarea den una breve explicación de lo que piensan hacer. Muchas veces, al verbalizarlo
o al someterlo a la opinión de otros, las tareas se aclaran y se encuentran tareas o riesgos
encubiertos que pueden disminuir la incertidumbre y mejorar la calidad de la estimación.

Problema 4: estado permanente de alerta

Déjame contarte una historia personal. Hace un tiempo, con un colega que disfruta tanto
del café como yo, comenzamos a reunirnos para buscar cafeterías de buen nivel. Ambos
trabajábamos en proyectos similares utilizando Scrum. Notamos que nos costaba mucho
reunirnos, pero casualmente lo conseguíamos cada dos semanas. Y mientras
disfrutábamos un café exótico en una de nuestras reuniones descubrimos el motivo de esa
peculiaridad: nuestros equipos estaban sincronizados y finalizaban su Sprint el mismo día.
El único día que teníamos tiempo era el segundo día de cada Sprint, porque todos los
demás días teníamos reuniones y actividades o se acercaba el temido día de entrega.
Como este ejemplo, muchísimos desarrolladores pasan por un estado permanente de
alerta donde cada dos semanas tienen que presentar una nueva versión de sus
aplicaciones, y, conforme van avanzando en complejidad y se acerca el final del proyecto,
cada una de estas iteraciones se vuelve más crítica y en ocasiones más difícil y compleja.
Esta es una de las críticas que se le hace a Scrum, que permanecemos con "deadlines" o
fechas de vencimiento inminentes cada dos semanas y tenemos que recorrer esta milla
extra y darlo todo como si se nos fuera la vida en ello. Dos veces por mes por tiempo
indefinido. Esto puede tener consecuencias negativas sobre los desarrolladores. Por
ejemplo, puede generar agotamiento y desgaste. Si la sobrecarga se extiende durante
mucho tiempo, en algunos casos las personas pueden generar casos serios de estrés. Y no
me refiero únicamente a estar un poco más malhumorado de lo normal. El estrés es una
enfermedad seria que puede tener efectos permanentes en la salud como, por ejemplo,
afectar el corazón. Debe ser tomado muy en serio por las empresas para evitar problemas
de salud en sus empleados. En general, se recomienda para estos casos que se mueva el
foco de trabajo de trabajar más y se comience a planificar mejor. Me encantaría pensar
que podemos evitar del todo trabajar tiempos extra y no quedarnos hasta tarde para
terminar alguna tarea urgente. Sin embargo, aunque esto puede reducirse, es muy difícil
eliminarlo del todo porque la naturaleza del desarrollo de software es lidiar con
incertidumbre, con elementos desconocidos y en algunos casos con el aprendizaje en
terreno desconocido. Esto usualmente va a repercutir en un consumo mayor de tiempo
para solucionar tareas. Pero lo que sí podemos prevenir es la mala planificación. Para eso
es importante no solo tener un panorama claro de los elementos que se van a
implementar, aclarar todas las posibles dudas técnicas antes de comenzar una historia y
consultar con todos los colegas para aprender de sus experiencias y descubrimientos. Así
podemos reducir el tiempo de aprendizaje y la resolución de una tarea. También, cuando
una tarea toma más tiempo del esperado, lo ideal es analizar los factores que hicieron que
ocurriera dicho retraso y tomarlos en cuenta a la hora de realizar las siguientes
estimaciones. Si de manera constante tenemos retrasos, tenemos que modificar nuestras
estimaciones porque estamos asignándoles menos dificultad de la que realmente estamos
encontrando.

Problema 5: Scrum tiene demasiadas reuniones

Una de las promesas de Scrum es que el equipo puede estar enfocado más tiempo dentro
del proyecto gracias a la reducción de procesos administrativos y nunca va a desperdiciar
valioso tiempo en informes, generar métricas, reportes o cualquier otra cosa que no sea
crear soluciones. Scrum nos promete libertad para poder trabajar a nuestro ritmo sin
preocupaciones ni obstáculos, pero posiblemente la crítica más común que vas a escuchar
tanto de los detractores de Scrum como de los mismos miembros de un equipo Scrum es
que las reuniones devoran su tiempo. Tenemos una reunión todos los días, llamada "el
Scrum diario". Tenemos también la reunión de planificación, la demostración del
producto, la retrospectiva, y en muchos casos tenemos reuniones paralelas con otros
miembros del equipo. Por ejemplo, si alguno de los miembros del equipo está trabajando
en una parte del código que otra persona ya trabajó previamente, es una buena idea que
le consulte para poder disminuir esa curva de aprendizaje o poder comprender mejor lo
que está ocurriendo en esa sección específicamente. Posiblemente, el momento más
difícil y donde se complican más las cosas es cuando tenemos ciclos de dos semanas
donde la primera semana podemos dedicarle tiempo al desarrollo, pero la segunda
semana tenemos todas las demás reuniones y rituales de Scrum. Todas ocurren al mismo
tiempo, justo en esos días cuando se necesita dedicar la mayor cantidad de tiempo,
recursos y principalmente concentración en el código. Si tienes que pasar una hora de
reunión en la mañana y luego pasar otras dos horas de reuniones de planificación y otras
dos horas en reuniones con diferentes miembros del equipo, perdiste la mayor parte de tu
día laboral en actividades que no son productivas. Peor aún, este tiempo laboral perdido
no se compensa y era particularmente crítico que lo dedicaras a desarrollar código. Acá el
problema no es tanto Scrum, es que no se respetan debidamente los tiempos que están
fijados para cada uno de los rituales. El Scrum diario no debe tardar más de 15 minutos.
Las demás reuniones también tienen un tiempo definido de acuerdo con la longitud del
Sprint. No respetar el tiempo definido para cada ritual no solo afecta la práctica de Scrum,
también tiene un efecto directo sobre la productividad del equipo.

Problema 6: el dueño de producto no es el usuario

En Scrum tenemos un rol llamado "el dueño de producto", y este tiene un rol clave porque
es quien le da forma al producto. El dueño de producto no es el jefe ni el director del
proyecto, sino que es una persona que tiene la visión más completa sobre el producto y su
rol es guiar al resto del equipo para concretar esa visión. Entre sus tareas comunes está la
de crear las historias de usuario. Una historia de usuario es una funcionalidad redactada
desde el punto de vista de la persona que lo va a utilizar y está enfocada para aportarle
valor agregado a este producto. Las historias de usuario son almacenadas por el dueño del
producto en un artefacto llamado "la bitácora de producto". La bitácora de producto
contiene todas las historias de usuario que el dueño del producto considera serían valiosas
para el proyecto. Eso no significa que van a ser implementadas, sino que son parte de la
visión ideal que el dueño de producto tiene. Al iniciar cada Sprint, el dueño del producto y
el resto del equipo se juntan para acordar cuáles de las historias de usuario serán
implementadas en la siguiente iteración. Con esta dinámica de trabajo, vemos que quien
tiene el mapa y define la ruta por la que van a transitar los equipos será el dueño del
producto. Sin embargo, tenemos una disonancia en este proceso que para algunos críticos
de Scrum afecta el resultado de todo el proyecto. La última palabra sobre un producto no
la tienen las personas que lo hacen, la tienen las personas que lo compran, los usuarios.
Pensemos en una empresa como McDonald's, que no estaría en el lugar en el que se
encuentra ahora con las ganancias y presencia global que tiene si hubieran desarrollado
únicamente el producto que le gustaba a su fundador Ray Kroc: la Hula Burger, una
hamburguesa con un enorme trozo de piña asado y queso cheddar. Su historia hubiera
sido muy diferente, pero, afortunadamente, tuvieron la visión de escuchar los gustos de
sus usuarios y darles exactamente lo que querían. El usuario es rey, es la persona que
eventualmente va a pagar los cheques de todos los que trabajan en el proyecto de forma
directa o indirecta. Sin embargo, los usuarios, las personas que usan el producto, no lo
diseñan. Es el dueño del producto quien lo representa. Si el dueño de producto no está en
una sintonía perfecta con los deseos, percepciones, intereses y aspiraciones de sus
usuarios, el producto puede tener un fracaso total y podemos convertir los grandes
esfuerzos e inversión de recursos en un desperdicio absoluto.

Antipatrones comunes de Scrum

Qué es un antipatrón
Scrum tiene una serie de reglas, rituales, estructuras, roles y artefactos que garantizan o al
menos intentan mantener un flujo de trabajo coordinado y en movimiento permanente.
Con sus rituales, Scrum se asegura de que todo el equipo se mantenga ordenado,
planificado y sincronizado. Con sus artefactos nos da una guía para trabajar y nos da el
mapa del camino que ya hemos transitado. Los roles se encargan de mantener el proyecto
en movimiento y controlarse mutuamente, además de colaborar, adaptarse y aprender en
conjunto. En Scrum tenemos una libertad controlada, porque, aunque somos libres de
elegir qué hacer y cuándo hacerlo y tenemos control sobre nuestro tiempo porque el
avance se basa en las tareas, no en las horas de trabajo, todo se realiza dentro de una
estructura predefinida. Pensemos como en una jaula que sostiene todo, pero con una
estructura flexible, moldeable y adaptable. Esta estructura funciona muy bien hasta que
deja de funcionar. Y cuando esto sucede, comenzamos a ver la aparición de malas
prácticas. No significa que Scrum es inútil, sino que está implementado mal o que, de
alguna forma, las sutilezas no han sido comprendidas por todo el equipo o alguno de sus
miembros. Entonces, ¿cómo es que Scrum es tan bueno y al mismo tiempo puede ser tan
malo? ¿Es acaso que Scrum produce software de mala calidad o es una mala práctica en sí
mismo? Bueno, no, no lo es, pero, como todo proceso, Scrum solo funciona si las personas
que lo aplican correctamente comprenden sus sutilezas y adaptan las necesidades
específicas para cada proyecto. El proceso de Scrum mismo tiende a dirigir las cosas en
cierta dirección, y si no estás poniendo atención puedes caer en la trampa de implementar
un antipatrón. El término "antipatrón" se aplica a algo que inicialmente parece atractivo y
una solución de fácil implementación pero que, eventualmente, lejos de solucionar un
problema, termina causando aún más. Los antipatrones se ocultan dentro de las buenas
prácticas de Scrum y parecen parte del sistema. Recordemos que Scrum es muy simple de
adoptar. Justamente esa simplicidad hace que algunas personas piensen que con solo
unos minutos ya lo dominan y que involuntariamente copien antipatrones de otros
equipos o de proyectos previos pensando que es la forma en que se hace correctamente.
Los antipatrones distorsionan las diferentes dinámicas y roles de Scrum y comienzan a
degenerar el sistema creando desgaste, ineficiencia, problemas de comunicación y,
principalmente, le impiden al equipo alcanzar las metas del proyecto. Usualmente, los
antipatrones vienen acompañados y raras veces se presentan solos. Así que una vez que
se detecta un antipatrón en el equipo, debemos estar vigilantes porque muy
posiblemente tengamos más de ellos escondidos.
Antipatrones del Scrum master
El rol del Scrum Master es el responsable de que se cumplan las reglas y procesos que se
definen en la guía Scrum. Esto lo logran a través de ayudar a todos los miembros del
equipo a entender la teoría de Scrum, sus prácticas, reglas y valores. El Scrum Master
también tiene un rol de líder sirviente. Eso significa que mientras se encarga de liderar y
guiar al equipo, también está a su disposición como facilitador para ayudarles a eliminar
cualquier elemento que bloquee u obstaculice su avance para completar tareas. Ahora
que comprendemos su rol básico, examinemos alguno de los antipatrones comunes en los
que cae el Scrum Master. Por ejemplo, uno de los más comunes es cuando el Scrum
Master confunde su rol de guía y pasa a un rol de jefe o "project manager" y desde este
punto comienza a asignarles tareas a los desarrolladores. Esto ocurre muy sutilmente. En
ocasiones, los equipos ni siquiera se dan cuenta de en qué momento ocurrió porque,
justamente, ese rol de liderazgo y guía tiene una muy delgada línea entre aconsejar y
recordar a los desarrolladores los éxitos y fracasos anteriores y asignar directamente una
tarea. Al hacer eso, el Scrum Master no solo está rompiendo los límites de su rol, también
genera un efecto negativo sobre el equipo porque distorsiona su capacidad de auto
organizarse. Los equipos de Scrum deben tener la habilidad de organizarse sin necesidad
de que ningún otro rol entre en funciones, porque son justamente ellos los que conocen
mejor el proyecto y conocen cuáles son las necesidades exactas y quién debe trabajar en
cada uno los puntos que necesitan atención. En esta misma línea encontramos otro
antipatrón: cuando al Scrum Master le cuesta ser cuestionado. Parte del ADN de Scrum es
la autoevaluación y adaptación constante, y todos los miembros del equipo tienen que
estar preparados para escuchar retroalimentación positiva y negativa. En muchos casos, el
Scrum Master cree que se encuentra en una capa diferente de la que están los
desarrolladores y, aunque siente que darles retroalimentación negativa les puede ayudar
a mejorar sus problemas, no está dispuesto a recibir lo mismo de las demás personas que
trabajan con él. En el extremo opuesto tenemos a los Scrum Master que evitan a toda
costa el conflicto. Un equipo que debe trabajar junto la mayor parte del día
definitivamente tendrá diferencias de criterio, pero muchos Scrum Master creen que la
discusión y la diferencia de esos criterios son sinónimo de pelea. Al contrario. El Scrum
Master debe facilitar las instancias para que se ventilen estos conflictos y, lejos de generar
peleas o desavenencias, utilizarlos para encontrar formas de resolverlos efectivamente.
Otro de los problemas que se encuentra frecuentemente entre los Scrum Master es el
exceso de personalización y cambios sobre los procesos. Por ejemplo, modificar
constantemente el tamaño de los Sprints, cambiar de hora y lugar el Scrum diario, cambiar
los días, frecuencia y tiempo dedicado a los diferentes rituales con el fin de buscar una
adaptación para el equipo. Esto en sí mismo no es malo, y la adaptación constante es
parte de Scrum, pero cuando se hace con demasiada frecuencia y, en especial, cuando se
hace sin tomar en cuenta la opinión de los demás miembros del equipo, termina
generando fatiga y desinterés por parte del resto de los miembros del equipo. Por último,
tenemos el extremo opuesto, que es el Scrum Master que no tiene ningún interés en
adaptar los procesos y, de hecho, termina huyendo del cambio muchas veces para evitar
trabajar de más o simplemente para no tener que pensar. La solución para este tipo de
Scrum Master es comprometerse más con su rol o buscar otros horizontes en su vida,
porque el rol de Scrum Master requiere compromiso con el proyecto.

Antipatrones del dueño de producto

El dueño del producto, como su título lo sugiere, es la persona que vela por los resultados
del proyecto. Sin embargo, el término "dueño" no significa que el proyecto es de su
propiedad, sino que establece una relación de control y responsabilidad con el producto.
Esto significa que el dueño del producto es la persona que se encarga de idear el proyecto
y de transmitir esa visión al equipo para que lo concrete. El dueño del producto en algunos
casos puede ser el cliente, pero esto no significa que tenga potestad sobre los demás
miembros del equipo. Y esa simple aclaración es importante porque es la raíz de muchos
de los antipatrones relacionados con este rol. Precisamente porque el dueño del producto
es el encargado de velar que se cumplan la mayor cantidad de tareas en cada Sprint es
que cae muchas veces en un antipatrón que es presionar al equipo para aceptar más
tareas de las que realmente pueden ejecutar. Es muy común ver que durante las
reuniones de planificación el dueño del producto trata de convencer o presionar a los
miembros del equipo para que acepten algunas tareas extra. Esta acción, que puede
parecer inocente o posiblemente la de un buen negociador, termina afectando
directamente el rendimiento del proyecto porque genera cifras infladas y proyecciones
incorrectas. En la misma línea tenemos a los dueños de producto que presionan a los
miembros del equipo para dar estimaciones más bajas, cuestionando la dificultad que
ellos pueden encontrar y sugiriendo que no tienen tanta pericia, por encontrar una tarea
tan compleja. Esta presión tiene el mismo efecto que el antipatrón anterior: genera cifras
incorrectas, en este caso con subestimaciones que a la larga implicarán que el equipo
tenga que trabajar tiempo extra para cumplir con los objetivos. Al ser el dueño del
producto el encargado de gestionar todas las historias de usuario y de administrar la
bitácora de producto, es también el responsable de la calidad y formato en que se
encuentran las historias de usuario, más específicamente dentro de ellas: los criterios de
aceptación. Si los criterios de aceptación no están claros, delimitados y completos, a la
hora de que el equipo presenta una tarea determinada, el dueño del producto usará
criterios de aceptación subjetivos o partes faltantes para rechazar una tarea y enviarla de
nuevo a producción. Esto tiene dos efectos negativos. El primero es que hace que esa
nueva funcionalidad en el producto se vuelva más costosa porque tuvo que recibir trabajo
adicional. Y la segunda es que el dueño del producto se puede sentir frustrado porque
siente que el equipo no le está presentando un resultado en las condiciones que exige.
Pero es imposible para el equipo cumplir con los criterios de aceptación inexistentes o
subjetivos. Finalmente, tenemos a los dueños de producto que creen saberlo todo. Ellos
distorsionan su rol de ser un líder que conoce a fondo el producto y presumen que tienen
todo el conocimiento posible. Cuando esto ocurre, no toman en cuenta las sugerencias y
opiniones del equipo de desarrollo sobre temas técnicos, tampoco escuchan a los
usuarios, y en muchos casos ni siquiera recopilan retroalimentación de ellos. Estos dueños
de producto ven al equipo como una simple herramienta para lograr su objetivo. El
producto resultante de un dueño de producto así es, generalmente, uno que tiene poco
éxito entre los usuarios y en muchos casos falencias técnicas por aplicar una visión
totalmente unilateral y no aprovechar un equipo multidisciplinario.

Antipatrones de las bitácoras de producto

La bitácora de producto es el repositorio donde se encuentran todas las tareas que
conforman la visión del proyecto. En la bitácora del producto están las historias de
usuario. Estas historias contienen nuevas funcionalidades que le aportan valor al usuario
final. Sin embargo, no necesariamente los elementos que se encuentran en la bitácora de
producto van a ser ejecutados. antes de eso tienen que pasar por un proceso de análisis y
retroalimentación del equipo de trabajo durante la ceremonia de planificación del Sprint.
Y es justo en este momento donde se reúnen todos estos elementos que se tiende a
encontrar algunos antipatrones. Por ejemplo, encontrar historias de usuario con formatos
incorrectos tales como historias que no tienen contenido, solamente un título o con
criterios de aceptación ausentes, sin respetar el formato correcto o sin un enfoque hacia
el usuario. Este tipo de tareas no hace más que generar confusión y hace que el equipo
pierda tiempo, ya sea aclarando el verdadero enfoque y alcance que tiene la historia,
como trabajando varias veces las tareas porque no cumplen con los criterios de
aceptación o no abarcan correctamente el alcance deseado. Otro problema es cuando las
tareas no se encuentran debidamente priorizadas antes de la reunión de planificación. En
muchos casos, cuando el equipo comienza a seleccionar tareas, asumen por defecto que
dichas tareas se encuentran previamente priorizadas. Y cuando comiencen a agregarse
dentro de la bitácora del Sprint, tendremos tareas de baja prioridad ocupando el tiempo y
recursos de tareas de la más alta prioridad. Asimismo, corremos el riesgo de que el dueño
del producto, al detectar el problema, quiera realizar cambios una vez iniciado el Sprint,
produciendo una distorsión en el enfoque, las estimaciones y, posiblemente, en la
resolución de los objetivos.

Antipatrones de las reuniones diarias

La reunión diaria es el momento en que todos los miembros del equipo se reúnen para
sincronizarse, planificar y detectar cualquier problema que puede afectarles a lo largo del
día en la resolución de sus tareas. De todos los rituales de Scrum, este es al que más veces
vamos a asistir y en el que posiblemente acumulemos más tiempo. Esto significa que, por
la gran cantidad de interacciones que vamos a tener con esta ceremonia, corremos el
riesgo de generar más antipatrones. Del primer antipatrón que te quiero hablar, y
posiblemente el más común, es tomar la reunión diaria como un método de control sobre
el equipo de desarrollo. Muchas veces se definen horas específicas de realización para
forzar a los desarrolladores a estar presentes en la oficina para ese momento. Por
ejemplo, hacer una reunión como primera acción del día para detectar si alguno de los
miembros llega tarde a trabajar o para hacer un conteo de cabezas y enterarse de si
alguno de los miembros no asistió a la oficina. Este patrón desvirtúa totalmente el
objetivo de la reunión y además introduce prácticas de microadministración, o
"micromanagement", como se le conoce popularmente. El tiempo laboral o la asistencia
de los miembros del equipo no es problema de Scrum y debe ser manejado por el
departamento de Recursos Humanos únicamente. Otro problema que ocurre en esta
reunión es cuando los miembros del equipo utilizan su tiempo para realizar únicamente
una actualización, y, peor aún, cuando el reporte de avance va dirigido hacia el Scrum
Master o el dueño del producto. Muchas veces estos dos roles, por su calidad de
liderazgo, se confunden con el rol de jefes. Pero en Scrum la figura de jefe no existe, todos
los miembros están al mismo nivel. Cuando un miembro del equipo toma la palabra
durante la reunión diaria, debe dirigirse a los demás miembros del equipo para
actualizarles y darles contexto sobre lo que se encuentra haciendo actualmente. Acá, la
interacción con el Scrum Master sería únicamente en caso de que tenga algún tipo de
bloqueo que le impida finalizar su trabajo del día. En la reunión diaria también ocurre otro
antipatrón común y es la mala interpretación de la asistencia que deben tener los
diferentes roles. A esta reunión generalmente asiste el Scrum Master, que es la persona
encargada de administrar el tiempo, asegurándose de que la reunión no tarde más de 15
minutos, que es lo que sugiere el manual de Scrum. Sin embargo, la presencia del Scrum
Master no es requerida. Con el dueño del producto ocurre el caso opuesto. Se asume que
no debería asistir a la reunión diaria y que solo debe participar de las reuniones de
planificación. El dueño de producto tiene recomendado asistir a la reunión diaria al menos
tres veces por semana para aclarar posibles dudas y profundizar su conocimiento sobre el
producto. El único rol que tiene la obligación de asistir a la reunión diaria es el equipo de
desarrollo. En el caso de que cualquier otro rol no asista, el equipo tiene la capacidad de
auto organización para realizar y organizar la reunión dentro de los parámetros de tiempo
y orden que ya conocen.

Antipatrones de las retrospectivas

La retrospectiva es un ritual de Scrum donde los miembros del equipo se reúnen para
analizar lo ocurrido dentro del Sprint. La retrospectiva se realiza al final del Sprint y, de esa
forma, nos garantizamos que los recuerdos y memorias están aún frescos para analizar en
detalle los éxitos y aciertos del equipo. Las retrospectivas son un ritual crucial para Scrum
porque es un momento de reflexión y autoanálisis en el que los miembros del equipo se
autoevalúan mientras dan y reciben retroalimentación de sus colegas. Toda esta
información se analiza en conjunto y se sugieren mejoras tanto para los individuos como
para el equipo, con el fin de prevenir las cosas que salieron mal y potenciar las que
salieron bien. El primer antipatrón que te quiero mencionar para estos casos es cuando no
hay retrospectiva del todo. Esto es más común de lo que te imaginas y se produce por
muchas razones diferentes. En algunos casos es porque se considera que la retrospectiva
es una pérdida de tiempo y se trata de reemplazar ese tiempo que se invierte en ella por
tiempo productivo. Otra de las razones es cuando se considera innecesario el concepto de
mejorar a través de la retroalimentación y que cada uno de los miembros del equipo debe
ser responsable de su propio crecimiento personal y mejora constante. al eliminar la
retrospectiva, perdemos muchos de sus beneficios. El primero es que en muchas
ocasiones sirve como una válvula de escape para que los diferentes miembros del equipo
ventilen los problemas que encuentran. Solo por esa razón ya es suficiente justificación
tener una retrospectiva, porque así le damos una opción a los miembros del equipo de
que puedan disminuir sus niveles de estrés y puedan, por lo menos, comunicar los temas
que más les angustian. La otra razón es aún más preocupante porque, si bien es cierto es
un argumento válido que todas las personas debemos buscar la mejora personal, en un
equipo, al interactuar con muchas otras personas que perciben nuestro trabajo y pueden
darnos una mejor opinión, o al menos una opinión desde otro punto de vista, muchas
veces nuestro ego no nos permite ver los principales problemas que tenemos. La
retrospectiva es un ejercicio de valentía donde sus participantes tienen que aprender
tanto a recibir como a dar sugerencias constructivas. Otro antipatrón que ocurre durante
este evento o ritual es convertirlo en una reunión de quejas, críticas y ataques. Si bien es
cierto es muy saludable tener una instancia donde podamos ventilar los problemas
relacionados con el proyecto, debemos evitar perder el enfoque de la retrospectiva. Es
completamente válido que alguien se queje por la carga laboral o por las interacciones con
otros miembros del equipo, pero no podemos convertir la reunión en un momento de
quejas. Tenemos que enfocarnos en dar y recibir retroalimentación porque, más que
quejarse, lo que necesitamos de la retrospectiva es que nos brinde soluciones pensadas
en conjunto por todo el equipo. Lo mismo ocurre cuando se convierte en una reunión
para sacrificar un chivo expiatorio. Es normal que alguno de los desarrolladores en algún
momento cometa un error que afecte al resto del equipo y también es normal que el
equipo se frustre. Este tipo de temas pueden mencionarse dentro de la retrospectiva, lo
que no debe hacerse es aprovechar este momento para culpabilizar y atacar a un
individuo. Los comentarios siempre deben ser constructivos y nunca personales. Otro
detalle que puede afectar negativamente en las retrospectivas es mantener exactamente
el mismo patrón. Esta reunión puede ser particularmente densa y en algunos casos hablar
de temas difíciles, por eso es recomendable que se trate de cambiar las dinámicas o
incluso el lugar donde se realizan. Esto para mantener al equipo motivado, pero también
para evitar caer en rutinas y no llegar únicamente a responder las mismas palabras una y
otra vez ante las mismas preguntas. Esta dinámica tiende a perpetuarse en el tiempo y
llega el momento en que una retrospectiva termina siendo una rutina totalmente
irrelevante, desperdiciando uno de los rituales más importantes y productivos de Scrum.

Herramientas de detección y corrección de antipatrones

Examen de los diferentes tipos de Burndown Charts
Los "burn down charts" o gráficos de quemado son una herramienta común en Scrum y se
utilizan para visualizar el progreso del equipo a través de la revisión del trabajo que queda
por hacer en comparación con el tiempo disponible. En general, los gráficos de quemado
van a tener dos ejes: uno donde vamos a ver la cantidad de ítems que tenemos, y el otro
donde vamos a ver el tiempo disponible. El gráfico va a representar la cantidad de tareas
que quedan registradas dentro de la bitácora del Sprint. Por ejemplo, asumiendo que
tenemos una cantidad estática de historias de usuario y la cantidad puede ser de 100, si
hoy se resolvieron 20 de ellas, al día siguiente 15, en poco tiempo tendremos 65, y así
sucesivamente hasta que lleguemos a cero. Esta es la apariencia común del gráfico donde
vamos a ver cómo disminuyen continuamente las tareas, desde el máximo hasta el
mínimo, a lo largo del tiempo, y al llegar al final significa que hemos alcanzado la meta.
Pero conociendo esa estructura ideal que debería tener una gráfica, podemos utilizarla
para detectar antipatrones activos dentro de nuestro proyecto. Por ejemplo, si tenemos
una gran cantidad de tareas que no disminuye en el tiempo y que se mantienen estáticas
hasta un punto cercano al final del plazo, tenemos un antipatrón donde el dueño de
producto no está aceptando las diferentes historias que le envía el equipo de desarrollo y
está postergando su aprobación. Esto genera un gráfico donde vamos a tener la línea
superior de tareas fija en el punto máximo, y de pronto vamos a ver cómo cae o del todo
se mantiene sin cambios durante todo el plazo. Este tipo de gráfico también nos dice que
hay gran cantidad de riesgo porque, al no tener estas historias aprobadas, es posible que
tengan problemas a la hora de examinar sus criterios de aceptación y que, si el dueño del
producto las rechaza, tengamos un flujo excesivo de trabajo. Esto puede significar que se
tenga que postergar el tiempo de entrega o que no se cumplan los plazos porque se
distorsiona completamente el flujo y las predicciones esperadas. Para solucionar este
problema, tenemos que involucrar más al dueño del producto presionándole para que
mantenga la menor cantidad de tareas sin revisar y que se mantenga en constante
comunicación con el equipo y los procesos. Otra anomalía que podemos detectar con este
gráfico es cuando tenemos un progreso particularmente lento. El patrón que aparecerá en
el gráfico es la línea mostrando la cantidad de tareas pendientes, que está muy por arriba
a la expectativa que deberíamos tener para cumplir a tiempo con el proyecto. Las causas
de un gráfico de este estilo pueden ser muchas. Por ejemplo, cuando tenemos equipos
muy ambiciosos que tratan de abarcar más tareas de las que realmente pueden manejar
al momento de planificación y que consideran que esas tareas pueden ser más fáciles y las
subestiman, pero al momento de trabajar descubren que eran más complicadas e iban a
tomar más tiempo. También tenemos equipos que son presionados tanto por el Scrum
Master como por el dueño del producto para aceptar más trabajo del que pueden asumir.
Sin importar la razón, en ambos casos tenemos el mismo resultado: se generó una
distorsión en las proyecciones, pero los resultados terminan siendo inferiores a lo que se
espera. Para corregir esto podemos hacer que el equipo mejore su capacidad de
estimación de tareas y reajustar a niveles más realistas las proyecciones de finalización.
Otro gráfico que nos puede revelar antipatrones es cuando tenemos olas que
representaron disminuciones y aumentos periódicos en la cantidad de tareas. Este gráfico
refleja que hay un cambio constante en el alcance del proyecto. Cuando el equipo cierra
una cantidad de tareas, llegan más para reemplazarlas y este proceso se repite múltiples
veces. La consecuencia directa de este tipo de acciones es que es prácticamente imposible
que el equipo llegue a terminar a tiempo el proyecto porque, sin importar la cantidad de
tareas que finalicen, llegarán más para reemplazarlas. En ocasiones, los equipos
comienzan con una cantidad de tareas y terminan un par de iteraciones después con dos o
tres veces más tareas de las que comenzaron. Acá podemos detectar varios antipatrones.
Por ejemplo, una bitácora dinámica donde tenemos la inserción de nuevas tareas
constantemente mientras el equipo está trabajando en esto. Y esto produce que, aunque
el equipo haya reducido la cantidad original de tareas, estas nuevas tareas que entran sin
generar ningún tipo de compensación de tiempo aumenten el alcance de la iteración y
hacen que el equipo siempre esté detrás de la expectativa de los resultados. La solución a
este tipo de problemas es mantener una posición férrea sobre los elementos que se
incluyen dentro de la bitácora del Sprint. En el caso de que se agreguen nuevos
elementos, deberá compensarse eliminando otros para no aumentar el alcance ni la carga
de trabajo. Otro antipatrón un poco más difícil de detectar y que puede generar este tipo
de gráficos es cuando el equipo no refina correctamente las tareas. Por ejemplo, cuando
se encuentran una tarea que es excesivamente compleja y no la dividen en partes más
pequeñas. El equipo debe subdividir estas tareas, pero al subdividirlas se genera una
visibilidad sobre la verdadera carga adicional y esto se va a ver reflejado dentro del
gráfico. Por último, tenemos un gráfico donde vemos una caída importante de las tareas
mucho antes del periodo esperado de finalización. Y si bien es cierto terminar a tiempo, o,
mejor aún, con tiempo de sobra no es precisamente un problema, sí puede revelar
antipatrones ocurriendo dentro de nuestro equipo. Terminar mucho tiempo antes de lo
esperado significa que el equipo está asignando una dificultad mucho mayor de la que
realmente tienen las tareas, y eso significa que están distorsionando los tiempos de
finalización por ser demasiado precavidos. La otra opción es porque los equipos están
agregando un "buffer" o colchón de tiempo en las estimaciones. Por ejemplo, si el equipo
considera que la tarea es medianamente difícil, pero hay varios elementos que le agregan
incertidumbres al Sprint, le agregan un nivel mayor de dificultad para que el sobretiempo
compense la incertidumbre. En ambos casos, la solución al problema es mejorar las
estimaciones y trabajar únicamente con aproximaciones realistas. En el caso de que el
equipo sea demasiado precavido, se puede ir ajustando paulatinamente el nivel de las
estimaciones dependiendo de los resultados e ir reduciendo estos números según el
avance del equipo. En el segundo caso, no se trata de que el equipo no incluya este
colchón, la solución está en tratar de evitar que exista riesgo. Para disminuir el riesgo, se
tienen que definir mejor las tareas, delimitar el alcance, mejorar el formato y aclarar al
máximo los criterios de aceptación. Eliminar las historias demasiado extensas disminuye al
máximo el riesgo y le quitamos al equipo la necesidad de compensar con
sobreestimaciones.
Siguientes pasos en el uso de antipatrones de Scrum
Los antipatrones son como los virus que afectan a Scrum. Comienzan de forma
aparentemente inofensiva y a veces imperceptibles, pero poco a poco comienzan a crecer
y a expandirse y multiplicarse hasta afectar todos los ámbitos del proyecto. Es
completamente comprensible que al conocer este concepto quieras evitar que los
antipatrones lleguen a tu proyecto. Al fin y al cabo, nadie quiere que su proyecto falle. Sin
embargo, al igual que con los virus del mundo real, tratar de eliminarlos por completo
puede ser una tarea desgastante e incluso imposible. Los antipatrones surgen a partir de
las personas, de las malas interpretaciones de la filosofía de Scrum y, en algunos casos, de
la falta de compromiso. Todas estas causas pueden aparecer muy fácilmente en cualquier
equipo, incluso en los que están altamente comprometidos. Puede ser que la falta de
pericia y de experiencia trabajando en Scrum termine generando antipatrones. La mejor
forma de prevenir los antipatrones no es eliminarlos, sino estar en un estado permanente
de vigilancia. Mantener un equipo motivado y comprometido con Scrum es una tarea
constante que debe cosecharse a lo largo de todo el proyecto. Lo mismo ocurre con
mantener las buenas prácticas y los principios que propone Scrum. Forzar la aplicación de
las reglas no soluciona directamente un problema, pero olvidarse de ellas,
definitivamente, atrae los antipatrones. Posiblemente, la métrica más importante para
detectar anomalías es observar los resultados del equipo. En un proyecto lo más
importante es finalizar a tiempo, cumplir con las metas y hacer realidad el concepto
original que tenía el proyecto, concretando la visión del cliente. Clientes satisfechos,
desarrolladores motivados y producción saludable son los indicadores de que el proyecto
está funcionando bien. Por el contrario, si alguno de estos elementos no está en el nivel
esperado, tenemos que comenzar a buscar cuáles pueden ser los problemas y los
antipatrones que nos están afectando. Para finalizar, la herramienta más importante que
tenemos dentro de Scrum es la capacidad de adaptación. No importa que encuentres
constantemente antipatrones, es parte de la naturaleza humana, y, como te he dicho
antes, prácticamente imposible librarse de ellos. Lo que sí puedes hacer es encontrar
soluciones en equipo para que no ocurran de nuevo y evitar que regresen.