Qué es scrum y qué lo hace especial

Scrum se define como un marco de trabajo ágil que permite a equipos y

organizaciones crear valor a través de soluciones que se adaptan a problemas
complejos. Es utilizado en todo el planeta para desarrollar y mejorar una muy
amplia gama de productos y servicios. Hoy en día es un estándar de facto en
muchos sectores. Por su flexibilidad y facilidad de uso se aplica desde en
emprendimientos con un puñado de miembros hasta en corporaciones con miles
de empleados y operaciones multinacionales. En mi experiencia trabajando en
scrum en pequeñas y grandes organizaciones me he encontrado con que muchas
veces se cree que scrum es una metodología o técnica de trabajo que si se sigue al
pie de la letra se convierte en una solución infalible. Me ha tocado ver líderes que
de pronto leen un artículo de scrum en una revista y se imaginan que con una
reunión diaria de 15 minutos mágicamente se aumentará la producción y, de paso,
les transportará en el tiempo para presentar los proyectos atrasados con días de
anticipación. Sobra decir que no hay nada más alejado de la realidad, scrum no es
una técnica ni una metodología y, menos aún, una respuesta para que todo
funcione a la perfección; consiste en un marco de trabajo, una serie de procesos y
guías para que los propios equipos generen espacios para mejorar y adaptar su
trabajo hasta encontrar el camino que mejor les funcione para dar con las mejores
soluciones. Parte de su popularidad se debe a que tiene muy pocas barreras. Para
comenzar, no necesitas ningún software, carrera universitaria, licencias o
infraestructura, por lo que se adapta a cualquier presupuesto y a organizaciones de
cualquier tamaño. Los procesos de scrum son fáciles de entender y comenzar a
utilizar. Cualquier miembro que se une a un equipo puede entender rápidamente la
dinámica de las reuniones y responsabilidades. Pero que no te engañe esta
facilidad. Entender scrum puede ser fácil, pero dominarlo toma tiempo, porque
siempre tiene un ángulo nuevo por descubrir y en el que hay que profundizar. Al
ser un marco de trabajo, está totalmente abierto para que dentro de él se apliquen
diferentes técnicas, según las preferencias y necesidades de cada organización. El
objetivo central de scrum es mantener un proceso constante de revisión,
adaptación y mejora hasta encontrar el punto de equilibrio perfecto para cada
producto y equipo de trabajo. Esto se hace porque todo proyecto maneja un grado
de incertidumbre y por incertidumbre me refiero a la falta de certeza de la
efectividad real que tendrán nuestros esfuerzos. Me ha tocado y, posiblemente a ti
también, ver equipos que no creen en la mejora constante y consideran que un
proyecto se planifica una vez y así está perfecto. Se pasan un año completo
desarrollando ese producto perfecto para descubrir, después de lanzarlo y agotar
sus recursos, que su producto no funcionaba bien con el público. Y ahora ya no
tienen posibilidad de corregirlo. Considera la incertidumbre de un producto como
una apuesta. Si no estás seguro de que vas a ganar, ¿es una buena idea jugar todo
el dinero a una sola apuesta? La incertidumbre es una constante y no podemos
evitarla. Por eso, scrum, de hecho, la abraza y procura disminuirla en varios
frentes. Por un lado, usando ciclos cortos de trabajo para reducir el costo de
posibles errores y, por el otro, con un proceso de mejora continua para que la
frecuencia de los errores se reduzca al máximo posible. Y, justamente, por eso
tantas empresas lo adoptan.

Las responsabilidades de scrum

Antiguamente conocidos como «roles», en scrum tenemos tres diferentes labores

especializadas. Cada una de ellas tiene una serie de tareas específicas por
realizar durante el desarrollo de un producto. En la versión más reciente de
scrum, se considera que un equipo scrum es un solo grupo de personas que
trabajan juntas y donde todos sus miembros tienen la misma jerarquía y
relevancia. Un equipo scrum está compuesto por un scrum master un product
owner y los desarrolladores. Este equipo scrum hace un trabajo iterativo, o sea, en
ciclos cortos llamados sprints, que se repiten continuamente. El objetivo de su
trabajo es crear mejoras para que, al final del ciclo, siempre se obtenga un
producto útil y de valor para sus usuarios. El sprint es la medida central de tiempo
en scrum. Puede tardar de 1 a 4 semanas, según las necesidades del producto, y,
durante el sprint, se llevan a cabo cuatro eventos: el scrum diario, donde el equipo
define un plan de acción para avanzar cada día; la planificación del sprint, donde se
crea un plan de trabajo para el siguiente sprint; la revisión del sprint, donde se
inspecciona el avance realizado y se proyectan los nuevos horizontes del
producto y, finalmente, la retrospectiva, un evento cuyo objetivo principal es buscar
formas de hacer al equipo más eficaz. Todo este trabajo se organiza a través de
tres artefactos y sus respectivos compromisos. El product backlog, o pila del
producto, donde se incluyen funcionalidades y mejoras que se desean incluir. Se
rige por el objetivo de producto, una guía que define hacia dónde se quiere llevar
el producto en el mediano y largo plazo. Luego está el sprint backlog, o pila del
sprint, una lista de funcionalidades o mejoras extraídas del product backlog, que
fueron seleccionadas para implementarse durante el sprint actual. Este artefacto se
rige por el objetivo del sprint, una guía que define hacia dónde se quiere llevar el
producto en el futuro inmediato. Por último, está el incremento, un artefacto que
registra todas las mejoras que fueron implementadas al producto y entregadas a
los usuarios. Para ingresar a este artefacto, se debe cumplir con la definición de
hecho, una serie de parámetros y requisitos de calidad definidos por la
organización o el equipo que controla que cada mejora cumpla con los estándares
del producto antes de volverse una parte integral de él. Estas son las partes y
conceptos fundamentales de scrum. Ahora que tenemos contexto, volvamos al
tema de las responsabilidades. Estas tres responsabilidades son las que
mantienen todos los procesos mencionados en funcionamiento. El product owner,
o propietario de producto, tiene la responsabilidad de maximizar el valor del
producto y de gestionar el product backlog, sus ítems y objetivos. El foco del
product owner es el producto y todos sus esfuerzos están centrados en
mejorarlo. Luego tenemos a los desarrolladores, antiguamente conocidos como el
«equipo de trabajo». Este nombre se eliminó para no crear la percepción de que
existían subequipos. Los desarrolladores son las personas, generalmente con
conocimientos técnicos relacionados con el producto, que tienen la
responsabilidad de tomar los ítems del sprint backlog y convertirlos en una parte
valiosa y funcional del producto. El foco de los desarrolladores es la
implementación, convertir ideas o conceptos en realidades concretas. Por último,
pero no menos importante, está el scrum master, la persona que tiene como
responsabilidad asegurarse que el equipo comprende y aplica correctamente los
principios de scrum y hace que el equipo sea lo más eficiente posible. A diferencia
del product owner y los desarrolladores, el scrum master no tiene responsabilidad
sobre el producto en sí; su foco son las personas del equipo y la organización.

El scrum diario

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
De todos los eventos de scrum, el scrum diario es, posiblemente, el más visible y
fácil de recordar para todos los que participan del proyecto, porque su frecuencia
es diaria y es usualmente el punto de encuentro para el equipo completo. El scrum
diario, como todos los conceptos de este marco de trabajo, parte de una premisa
muy sencilla: una reunión de 15 minutos en total donde participan todos los
miembros del equipo para adaptarse a cualquier cambio y crear un plan de acción
para el día. Sin embargo, tiene una serie de características y sutilezas que debemos
tomar siempre en cuenta para que esta pequeña reunión tenga el máximo efecto
en nuestro equipo. El primer factor que debemos considerar es el tiempo. A
diferencia de la clásica reunión de trabajo donde el mismo calendario le asigna 1
hora de duración por defecto y, prácticamente, en todos los casos terminamos
tardando mucho más que eso, tenemos apenas 15 minutos de principio a fin. ¿Por
qué tan poco tiempo? Bueno, no es casual. La principal razón es mantener a los
miembros del equipo concentrados y no perder su atención. Todos, en algún
momento, hemos quedado atrapados en una de esas reuniones
interminables. Sabemos por experiencia que después de los primeros 30
minutos prácticamente nadie está poniendo atención y, dependiendo de la hora,
algunos hasta comienzan a dormirse. Otra razón para que esta reunión sea tan
corta es para forzar a todos a mantenerse dentro del tema. Cuando las reuniones
no tienen límite de tiempo, la gente tiende a divagar con asuntos ajenos al
proyecto y a consumir horas y horas que podrían ser productivas con temas que no
le aportan nada al equipo. 15 minutos distribuidos entre todos los
participantes también obligan a mantener equipos pequeños, que tienden a ser
más productivos y a tener un conocimiento más profundo del producto. Sin
embargo, es importante mencionar que, aunque se aconseja una duración de 15
minutos, es común y perfectamente normal que el scrum diario se extienda o
acorte algunos minutos según la actividad del día sin que esto afecte de forma
particular su funcionamiento. Siempre será más importante que alguien termine de
explicar su idea antes de interrumpirle y dar por terminada la reunión porque se
pasó el tiempo. Tradicionalmente, esta reunión tenía un formato muy específico de
participación, donde cada miembro del equipo tomaba la palabra para responder
tres preguntas: ¿cuál fue mi avance el día de ayer? ¿Qué estoy planeando hacer el
día de hoy? ¿Y qué problemas o bloqueos me impiden avanzar en mis objetivos
diarios? Este formato, aunque sigue siendo perfectamente válido, se eliminó de la
guía oficial de scrum para abrirse a la posibilidad de que el equipo pueda
escoger cuál es el estilo que mejor se ajusta a sus necesidades. El objetivo principal,
ahora, más que hacer un informe de trabajo, es que el equipo genere un plan de
acción que adapte y corrija el rumbo, con la mira puesta en alcanzar los objetivos
del sprint. Privilegiamos la efectividad sobre todas las cosas. El scrum diario debe
llevarse a cabo, siempre que sea posible, a la misma hora a fin de evitar
confusiones y mantener una agenda simple. En caso de que se ejecute en un lugar
físico, debe ser en una habitación con la menor cantidad de interrupciones
posibles. Si bien es imprescindible que los miembros del equipo participen de este
evento, porque son quienes mantienen el movimiento y el avance del sprint, esta
reunión está abierta para cualquiera que desee conocer el estado del proyecto. Sin
embargo, estas personas externas al proyecto de trabajo solo pueden ir en calidad
de oyentes y no participar, para mantener la reunión acotada y no exceder el
bloque de 15 minutos.

El sprint, piedra angular de scrum

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
El sprint es la piedra fundamental del scrum. Consiste en un bloque de
tiempo durante el cual se desarrolla el proyecto. En el transcurso de este periodo,
los miembros del equipo se dedican a cumplir con los objetivos que definieron al
inicio del sprint. El sprint es la unidad de tiempo cíclica con la que trabajamos en
scrum. Su duración es relativa a muchos factores, como la complejidad del
problema que se busca solucionar, el tipo o madurez del producto que se
desarrolla o las capacidades y el número de integrantes del equipo. Como regla
general, un sprint tiene una duración máxima de un mes, pero es común que cada
equipo ajuste ese tiempo y es fácil encontrar proyectos que trabajan
exitosamente en sprints de una, dos o tres semanas. Reducir el ciclo del sprint
ayuda, en muchos casos, a adaptarse a proyectos más dinámicos, en especial
cuando los cambios son rápidos y las tareas menos complejas. Por otro lado,
aumentar la duración ayuda en casos que sea necesario hacer muchas pruebas de
control de calidad o las tareas comunes sean más complicadas. Aunque es
perfectamente normal ajustar el tiempo del sprint, siempre debe ser una decisión
que se toma involucrando a todo el equipo y el plazo máximo de un mes se debe
mantener intacto. Como todo en scrum, hay varios motivos detrás de esta
medida. Por ejemplo, al mantener un máximo de un mes de avance acumulado, se
limita el grado de complejidad del trabajo. Se previene que los miembros del
equipo se desgasten en procesos demasiado largos y, en especial, permite ajustar
el rumbo constantemente. Una vez transcurrido el sprint, se inicia otro
inmediatamente después. Así, nos mantenemos en un proceso de mejora y
adaptación constante. Cada sprint debe ser individual y separado del anterior. Por
eso, antes de comenzar, se deben definir los objetivos del sprint y crear el sprint
backlog, que será el trabajo que el equipo se compromete a realizar durante el
sprint. Así, se mantienen los esfuerzos del equipo enfocados en un punto común y
se aporta transparencia al proceso. Por ejemplo, si estamos trabajando en un
producto de software para un gimnasio, podemos definir como objetivo del
sprint que sea posible crear y administrar un perfil de usuario. Una vez definido el
objetivo, el equipo selecciona elementos del product backlog que tengan relación
con esa meta. Al final del sprint, se agregan los cambios que se ajusten a la
definición de hecho del producto. Y se termina con un producto cien por ciento
funcional y usable. Siguiendo el ejemplo anterior, si el objetivo del sprint era
permitir que se pudieran crear y administrar perfiles de usuario, esta nueva
capacidad debe estar totalmente operativa, sin errores y lista para que cualquier
usuario la pueda utilizar de inmediato. Para cumplir con la meta del sprint, no solo
debemos tener un plan, hay que estar preparado para adaptarse. Por eso, aunque
los objetivos deben conservarse, el equipo puede sugerir cambios en los
detalles conforme van conociendo mejor el producto o avanzan en la
implementación. Continuando con nuestro ejemplo, podemos mantener la
creación de perfiles de usuario. Pero el equipo descubre a la mitad del sprint que,
una vez implementada la solución, se abre una brecha de seguridad en la
aplicación y es necesario hacer una autenticación de dos pasos para mantener el
servicio funcionando sin problemas. Todo proyecto puede cambiar
inesperadamente o, peor aún, las cosas pueden salir mal. El objetivo del sprint es,
por un lado, implementar mejoras que aporten valor al producto, pero
manteniendo periodos relativamente cortos de trabajo para contrarrestar el
riesgo. Este sistema busca reducir al máximo la incertidumbre y tener resultados
rápidos. Así, si las cosas salen mal o si se descubre que los usuarios no encuentran
valiosa esta nueva funcionalidad, solamente se pierde, como máximo, un mes de
trabajo y es posible rectificar inmediatamente.

La planificación del sprint

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Tener una ruta clara de lo que debemos hacer es crítico en cualquier
proyecto, porque si no sabes dónde está exactamente la meta, ¿cómo te enteras de
que terminaste la carrera? En scrum, tenemos un evento llamado la «planificación
del sprint», que es el momento en el que se delimita cuál será el plan de acción del
equipo en la siguiente iteración del proyecto. Debido a que los sprints continúan
uno detrás del otro, la planificación del sprint debe completarse, de preferencia, en
el transcurso del sprint anterior. Así, desde el momento en que arranca el modo
sprint, ya todo está debidamente planificado y todos los miembros están listos
para comenzar a trabajar de inmediato. La planificación del sprint es una
reunión donde deben participar activamente todos los miembros del proyecto. Esta
reunión tiende a ser extensa, porque se deben discutir en detalle todos los temas y
acciones que tomará el equipo en el próximo ciclo de trabajo. Sin embargo,
también está limitado a un tiempo definido de hasta 8 horas para sprints de un
mes o el tiempo proporcional para sprints más cortos. En otras palabras, para un
sprint de 2 semanas, el límite sería de 4 horas. Por la extensión e importancia de
esta reunión y para no agotar a los asistentes, es perfectamente posible dividirla en
varias sesiones o bloques hasta completar el proceso de planificación. Una
herramienta indispensable para realizar la planificación del sprint es el product
backlog, que es una lista donde se incluyen todos los requisitos y
funcionalidades que se desean del producto. Esta lista puede tener una longitud
indefinida y puede ir desde lo concreto hasta elementos que aún no están en
capacidad de realizarse. Durante la planificación del sprint, todo el equipo en
conjunto decide el objetivo principal que desean cumplir y se toman las
funcionalidades relacionadas desde el product backlog. Antes de comenzar a
trabajar en la planificación, el equipo debe plantearse tres preguntas básicas: ¿por
qué este sprint es valioso? ¿Qué puede hacerse en este sprint? ¿Y cómo se
conseguirá acabar el trabajo seleccionado? Para responder la primera pregunta, el
product owner muestra al resto del equipo los intereses de negocio del producto
en corto plazo. Con esta información, todos los miembros del equipo en conjunto
deciden el objetivo del sprint para alinearse en un propósito común y maximizar el
valor del producto. Luego, para saber qué se puede hacer durante el sprint, se
contempla el estado actual del proyecto, los recursos disponibles o las variables del
tipo temporal que pueden afectar al producto, como estaciones o festividades. Una
vez realizado el análisis, se seleccionan tareas del product backlog y eso se
convierte en sprint backlog, el trabajo que será implementado durante esta
iteración. Por último, se realizará un análisis detallado de todas las tareas,
requerimientos técnicos y dependencias para detectar los posibles obstáculos y
tener una visión de lo que se necesita para concretar esta implementación. Vamos
a imaginarnos cómo sería la planificación del sprint en el mundo real. Supongamos
que estamos desarrollando un proyecto de software bancario y en el product
backlog tenemos requerimientos como permitir transferencias entre cuentas, la
capacidad de revisar mis saldos, la autenticación en dos pasos, el soporte para
criptomonedas y mensajería en tiempo real. El equipo se reúne y, después de
revisar el product backlog, decide que ya se acerca la temporada navideña. El tema
del siguiente sprint debe ser el soporte para transferencias entre cuentas, así que
se selecciona esa tarea en particular. Pero como la autenticación en dos pasos y la
capacidad de revisar el saldo están relacionadas y aportan funcionalidad al objetivo
del sprint, también son elegidos. Los demás requerimientos del product backlog 

La revisión del sprint

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
A lo largo del sprint el equipo de scrum se encargó de implementar todos los
objetivos que fueron definidos durante la etapa de planificación. Al terminar este
ciclo, se ejecuta la revisión del sprint. Para esta reunión, el equipo, en
conjunto, inspecciona los resultados concretos del trabajo realizado en el sprint
que finaliza. La revisión del sprint es una reunión informal, casi un paso natural
para un equipo que ya está totalmente familiarizado con el producto. Debemos
evitar convertir esta reunión en una demostración de lo que es el producto o usar
un grupo de diapositivas para mostrar objetivos generales y cifras. La revisión del
sprint es una inspección del producto en su estado actual, haciendo énfasis en las
nuevas posibilidades que tiene gracias a sus mejoras. Cada equipo y organización
puede desarrollar su propio formato, por ejemplo, se puede comenzar
explicando cuál era el objetivo del sprint y, a partir de allí, examinar las diferentes
novedades que se incluyeron en el producto durante este periodo. Es posible
también contrastar los cambios de manera que cada tarea esté vinculada a un
proceso de demostración en el mundo real, por ejemplo, si en un equipo estamos
creando un software para el manejo de restaurantes y durante el sprint el objetivo
fue mejorar el flujo de las comandas y facilitar el cálculo de las propinas. En este
caso, uno de los miembros del equipo puede comenzar mencionando algunas de
las mejoras implementadas, como el flujo de los pedidos. Una vez detallados
brevemente los objetivos, se procede a explicarle a los demás cuáles fueron los
cambios que se aplicaron en el sprint y cómo el producto mejora gracias a
ellos. Siguiendo el ejemplo de este software para restaurantes, se agregó un
sistema de mensajería de voz entre los meseros y la cocina para hacer más
eficiente el proceso de pedidos. Para mostrar el resultado, se debe abrir la
aplicación y ejecutar el flujo completo del pedido usando el nuevo sistema de
mensajería en una situación realista, mostrando todos los cambios y las
mejoras, además del impacto positivo del producto. Otro punto valioso que debe
compartirse durante la revisión es la de todas las evidencias empíricas y
descubrimientos que tuvo el equipo, así como los retos o problemas encontrados y
cómo se solucionaron. Supongamos que nuestro equipo de software para
restaurantes tuvo problemas con el sistema de propinas porque, luego de
implementarlo, descubrieron que no en todos los países las propinas se calculan
igual. Debido a esto se decidió incluir un sistema de geolocalización enlazado a
una tabla de opciones que calcula la propina correspondiente para cada país. Esta
nueva evidencia es útil, no solo para conocer la productividad del equipo, sino que
puede ayudar a otros equipos trabajando en este software para que ahorren
tiempo y no cometan el mismo error. Incluso podría incorporarse en la definición
de hecho para garantizar que se cubren todas las condiciones legales en todos los
países que opere el software que se desarrolla. Una vez terminada la revisión de los
objetivos y tareas cumplidas en conjunto con su correspondiente demostración
funcional, se pasa a una segunda fase igualmente valiosa, que es la de análisis de
esta nueva versión del producto y qué posibilidades se abren con las mejoras. Si
continuamos con el ejemplo de el software del que estábamos hablando, ahora
que se tiene un sistema de mensajería incorporado, además del soporte para
diferentes condiciones operativas en diferentes países, 
La retrospectiva finalizado el sprint

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
La mejora de adaptación constante son los pilares fundamentales de scrum y el
mejor momento para que los equipos maduren y alcancen a plenitud estos
valores, es durante la retrospectiva. En scrum, la retrospectiva es una pausa que se
toma el equipo para analizar los resultados, evaluarse así mismo, y, principalmente,
buscar formas de mejorar. Como todas las reuniones que tenemos en scrum, la
retrospectiva es de un tiempo variable, pero está limitada a tres horas máximo para
un sprint de un mes. Conforme se reduce el tiempo del sprint, se reduce
proporcionalmente el tiempo máximo para la retrospectiva. El momento de llevar a
cabo este proceso es justamente al final del sprint, pero antes de comenzar el
proceso de planificación. Precisamente, porque es aquí cuando tenemos muy claro
todo lo que ocurrió durante el sprint anterior. Y tenemos la oportunidad de
identificar todos los errores y aciertos para tomarlos en cuenta antes de planificar
la siguiente etapa. Durante la retrospectiva el equipo se reúne y sus miembros
analizan los éxitos y lo que salió bien durante el sprint. Además de los errores, los
fracasos y los problemas que ocurrieron en el ciclo que termina. En una reunión
como esta donde se habla específicamente de lo que sale mal, en algunos grupos
tiende a convertirse en un momento para discusiones personales y para buscar
culpables. Pero nada está más alejado a su objetivo central. En una retrospectiva
buscamos generar una conversación sana donde predomine la autocritica, se
relacionen los errores a situaciones, no a personas, y todo se asuma como un
equipo. Los errores, así como los éxitos, siempre son mérito del equipo, no de los
individuos. Por ejemplo, si durante el sprint se fijó como objetivo reducir los
tiempos de carga de la web de la empresa en un 50 % y el objetivo no se logró no
se trata de atacar al desarrollador frontend y a pedirle su renuncia, si no de
identificar el problema y buscar la causa. En este caso, puede ser que se trate de
que los servidores tenían un rendimiento malo o que se trabaje en un sitio con
demasiadas imágenes y videos que toman demasiado tiempo en cargar. Una vez
identificado el problema, ya sea humano o técnico, se debe planificar una solución
en conjunto y asignarla a uno o varios miembros que se encarguen de que ese
problema no se repita. La retrospectiva no solo se trata de buscar problemas. El
objetivo es usar la experiencia para encontrar formas de hacer el equipo más
eficiente. De ser posible, se debe documentar el resultado de esta
reunión anotando lo bueno, lo malo, y las posibles soluciones con sus respectivos
responsables. Esto permite darle un seguimiento en la siguiente retrospectiva. Así
podemos identificar patrones positivos y negativos, así como el avance en la
implementación de las sugerencias que se hicieron en el sprint anterior. Para
algunas personas la retrospectiva puede ser intimidante y algunos hasta intentan
eliminarla o no asistir a ella. Pero una buena retrospectiva debe dejar a las
personas del equipo más que con una sensación de culpa con una motivación para
mejorar el equipo. Es un momento para pensar nuevas ideas y mejores formas de
hacer las cosas. Si encontramos que el equipo tiene un problema recurrente con
algún tema, como grupo, podemos encontrar una forma creativa para mejorar y
usar el siguiente sprint para experimentar nuevas formas de hacer las cosas. Las
retrospectivas nos ayudan a generar visibilidad 

Qué es un scrum master

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Probablemente la figura más visible y la que más sencillamente podemos
relacionar con el concepto de scrum es el scrum master. El scrum master es una de
las responsabilidades de scrum y frecuentemente les encontramos en el medio del
proyecto conectando todas las partes para generar una unidad funcional. Antes de
analizar qué es un scrum master, comencemos definiendo qué no lo es, porque
precisamente por ese papel central y la capacidad de interactuar
frecuentemente con todos los participantes del proyecto es que debemos poner
especial atención y evitar que se aplique incorrectamente. La primera cosa que no
es un scrum master es un project manager, o administrador de proyectos. Los
administradores se encargan de analizar el proyecto y planificar el trabajo que
debe realizarse; asignar diferentes tareas a los demás miembros del equipo y
asegurarse de que todas las personas a su cargo cumplan con sus horarios de
trabajo. Un scrum master no realiza ninguna de esas tareas y deja que sea el
equipo quien se autogestione en estos temas. Tampoco es un secretario que debe
tomar notas, enviar correos o realizar minutas de las reuniones. Cada miembro del
equipo tiene responsabilidades específicas y se encarga de organizarse a su
conveniencia personal. El scrum master no es un cliente que debe tener
control sobre el trabajo de los desarrolladores ni tampoco es la persona
responsable del producto y sus mejoras. Y en particular, no es el jefe del
equipo. Nadie tiene que hacerle reportes de horas o justificarle su avance diario. El
scrum master es un miembro más del equipo scrum al mismo nivel jerárquico que
todos los demás. Posiblemente te parezca confuso todo esto porque
tradicionalmente estamos acostumbrados a que en un equipo tiene que existir una
figura principal que le diga a los demás qué hacer. Pero eso es parte del paradigma
de scrum. Nosotros nos basamos en la confianza mutua y el trabajo en equipo para
remar juntos hacia la misma meta. Veamos ahora lo que realmente hace un scrum
master. La primera responsabilidad del scrum master es asegurarse de que el
equipo ejecute el marco de trabajo tal y como se define en la guía oficial. Esto
implica no solo organizar los diferentes eventos y verificar que se apliquen
correctamente las diferentes responsabilidades y roles de scrum, sino también
asegurarse de generar los espacios y crear una cultura propia en donde los
miembros del equipo estén comprometidos con el producto y tengan conciencia
de la importancia de trabajar en este marco de trabajo. Otras de las
responsabilidades del scrum master es potenciar la efectividad del
equipo. Importante distinguir eficiencia y efectividad. La primera busca que se
realice más trabajo en menos tiempo. La segunda es más importante y define qué
tanto efecto o impacto tiene el equipo en la evolución de un producto. Finalmente,
entre las responsabilidades del scrum master tenemos que deben ser líderes que
ayudan a sus equipos y en general a su organización, siendo agentes de cambio
para crear una verdadera cultura ágil. Muchas veces los scrum masters entran a
trabajar en organizaciones que no tienen una cultura ágil, que mezclan roles y
responsabilidades o hasta les exigen trabajar como project managers. Me ha
tocado estar en esa situación y sé que es algo que pasa con frecuencia. Pero la
misión de los scrum masters es no quedarse en una actitud pasiva, solo quejándose
de lo mal que se aplica scrum en su organización, sino convertirse en agentes de
cambio. Tal vez ese cambio no se logre en el corto plazo, pero poco a poco,
demostrando el valor y los aspectos positivos de scrum, deben guiar hacia una
verdadera adopción del rol y de la cultura ágil. Para resumir, el scrum master no
debe considerarse como un jefe ni una figura de control. Es más bien un agente de
cambio, un mentor que se encarga de que se trabaje bajo los parámetros de
scrum. 

Funciones y características de un scrum master

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Ejercer el papel de scrum master requiere de una serie de habilidades muy
particulares y aunque parece, muchas veces, un rol sencillo, necesita un gran
compromiso y vocación. El trabajo del scrum master gira en torno a mantener al
equipo funcionando dentro de los parámetros de scrum y a ser líderes, mentores
de su equipo. Para alcanzar sus objetivos, un scrum master debe, sin duda, ser una
persona con excelentes habilidades de comunicación que pueda crear puentes
comunicacionales entre personalidades que pueden ser muy distintas, pero que
deben trabajar codo a codo. También se necesita que sea una persona
empática, que tenga la capacidad de identificarse con los demás, comprender
cuando alguien tiene dificultades para asimilar su rol o los valores de scrum y
dedicar tiempo para convertirse en auténticos mentores, que conviertan a sus
compañeros en líderes. El scrum master también ayuda a que el equipo remueva
potenciales bloqueos que afectan la entrega. Por ejemplo, imaginemos que
estamos en un proyecto para escribir un libro de cocina y, durante este sprint, se
está trabajando en el diseño de la portada. Si uno de los miembros del equipo dice
que no puede avanzar en su trabajo porque aún no le entregaron las imágenes de
la sesión fotográfica con la cual se va a ilustrar el libro, el scrum master entra en
acción en dos frentes. El primero es ayudar a que el equipo no se
detenga, organizando una reunión rápida para que los desarrolladores reajusten su
plan de acción y analicen qué hacer. Por ejemplo, que mientras ese desarrollador
espera, colabore con otro que tiene una tarea particularmente difícil y le vendrá
bien una ayuda extra. El segundo frente por donde ataca un scrum master un
problema es analizando qué lo provoca y cómo prevenir que ocurra. En este caso,
si el equipo se ha atrasado varias veces esperando fotografías, sugerir que ese
tema se discuta en la retrospectiva y que el equipo analice opciones de cómo pedir
con más tiempo las fotografías o cambiar de proveedor. Como ves, durante sus
interacciones con el equipo, el scrum master establece un ambiente donde el
equipo puede ser eficaz, no se limita a eliminar un obstáculo, sino que guía al
equipo para que se mantenga igual de productivo y no pierda de vista los objetivos
del sprint en ningún momento. Para mantener la productividad alta, él o la scrum
master debe conocer a fondo su equipo, la personalidad de cada miembro, sus
fortalezas, los puntos débiles y el historial del proyecto para identificar las
dinámicas y los patrones que influyen en los resultados. Esto significa que, al
menos en etapas tempranas, debería tener sesiones personales con frecuencia para
conocer a fondo a cada uno de los integrantes. El scrum master aporta,
además, una importante información empírica, usando como referencia situaciones
anteriores. Supongamos que un equipo que desarrolla una aplicación móvil está
motivado y tiene la productividad alta, pero el scrum master detecta que en este
sprint van a trabajar con una nueva funcionalidad de Android y, en el pasado, cada
vez que el equipo trabajó con nuevas funcionalidades de este sistema
operativo, terminaron asignando más tiempo del planificado y surgieron retrasos
en la entrega. En este caso, hemos identificado un patrón y el scrum master debe
mencionarle al equipo su preocupación, al mismo tiempo que colabora con
ellos para repensar el flujo de trabajo y evitar que se repitan las mismas
condiciones del problema. 
Interacción del scrum master con los desarrolladores

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Desarrolladores y scrum master trabajan codo a codo  para sacar adelante un
proyecto y mantienen una relación muy cercana durante toda la etapa de
desarrollo. Al ser todos miembros del mismo equipo, entre el scrum master y los
desarrolladores no debe existir una relación de poder sino de liderazgo. Por
extraño que pueda sonar para muchos, el scrum master no tiene ninguna autoridad
sobre los desarrolladores, así que está fuera de su alcance tomar decisiones sobre
lo que se hace, asignarle una tarea particular a alguien, opinar sobre el código de
un desarrollador o despedir a alguien por no obedecer. Al contrario, el nivel de
comunicación con los desarrolladores siempre debe ser de iguales y en un entorno
de confianza. En este punto es común que me pregunten: «Entonces, si nadie tiene
autoridad sobre los desarrolladores, ¿cómo el scrum master se asegura de que el
trabajo se realice?» Y la respuesta es que esto no es responsabilidad del scrum
master. El scrum master se encarga de enseñarle a los miembros del equipo
scrum cómo trabajar usando este marco de trabajo. También ayuda a interiorizar
los conceptos que contienen los principios de scrum, tales como la transparencia,
inspección y adaptación constante. Un buen scrum master no se queda de brazos
cruzados si su equipo está desmotivado o sencillamente no manifiesta interés en el
producto y pone todo su esfuerzo en guiarle no solo a conocer, sino a aplicar a
diario en su trabajo los cinco valores de scrum que son: el compromiso,
enfoque, apertura, respeto y coraje. Por supuesto que no es un trabajo fácil
cambiar del paradigma de trabajo, pero con esfuerzo y constancia, tarde o
temprano, estos términos dejan de ser palabras vacías y se convierten en una
cultura, en parte del trabajo diario, y las personas pueden ver mejoras notables en
su calidad de vida. Es importante ir más allá de los discursos, convertirse en líderes
que enseñen aplicando en carne propia estos principios y fomentándolos al punto
que sea imposible no ver sus beneficios. Otra de sus funciones es guiar al equipo
para que utilice información empírica para estimar el esfuerzo de una tarea. Puede
buscar patrones donde el equipo tenga aciertos o errores comunes y darles
visibilidad para que facilite la adopción de buenas prácticas o la creación de
protocolos para evitar los errores comunes. Cuando tenemos desarrolladores
comprometidos que saben que existe confianza en sus habilidades, que hay una
pertenencia con el producto porque son ellos quienes definen el mejor camino
para la implementación, nadie necesita que le digan qué hacer o que le controlen
su horario laboral, porque existe una cultura de trabajo ágil donde cada persona se
autogestiona. Ese es el verdadero aporte que tiene un scrum master para una
organización y para su equipo.

Interacción del scrum master con el product owner

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
El scrum master y el product owner son en apariencia muy similares y hasta
coinciden en varias partes del proceso. Sin embrago, sus prioridades y enfoques
son totalmente distintos. Por un lado, el scrum master se va a relacionar con el
producto y el product backlog desde la perspectiva del equipo y se encargará de
mantener la agilidad para que todos los participantes del proyecto tengan un
entorno de trabajo que favorezca crear y aportar valor al producto. Por otro lado, el
product owner, enfoca su rol desde la perspectiva del producto tratando de
agregarle valor a través de las tareas que agregue en el product backlog. El punto
de coincidencia más frecuente entre estas dos responsabilidades, es justamente, en
el backlog de producto. Cada uno de ellos aporta ideas desde su perspectiva para
lograr un equilibrio a la hora de contribuir, expandir y enriquecer todas y cada una
de las tareas del proyecto. En scrum el product backlog es responsabilidad del
product owner quien tiene la responsabilidad de gestionarlo, definir sus
objetivos, y decidir, en última instancia, qué ítems pueden quedarse o deben
salir. Sin embargo, el aporte del scrum master y su conocimiento del equipo son
clave para elegir acertadamente las tareas para el siguiente sprint. Un buen trabajo
en equipo entre el scrum master y el product owner es determinante para que el
product backlog tenga mayor probabilidad de implementarse a cabalidad. Detalles
como los retos tecnológicos, los recursos disponibles y las fortalezas o debilidades
del equipo, tendrán así la visibilidad correcta. El scrum master también puede
guiar y darle herramientas al product owner para definir y mejorar conceptos como
el del valor del producto usando su experiencia y conocimiento ágil para mostrarle
las diferencias entre agregar nuevas capacidades y agregar valor. Entendiendo que
las capacidades o funcionalidades nuevas no significan nada si no producen una
mejora o impacto positivo para el usuario del producto. Para esto puede, por
ejemplo, mostrarle experiencias y procesos similares 

El scrum master en el scrum diario

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Una de las principales responsabilidades del scrum master durante el scrum
diario es organizar el evento o facilitar un entorno propicio para que se
complete con la menor cantidad de interrupciones y distracciones
posibles. Además de conseguir que se cumplan las reglas básicas como, por
ejemplo, que la reunión dure 15 minutos y mantener acotada la participación de
los miembros. Sin embargo, un error típico es considerar que el scrum master es el
protagonista del scrum diario. Muchas veces, los miembros del equipo le hablan
directamente como si fuera esta persona a la que deben informar el estado del
proyecto. Por el contrario, la función del scrum master en este evento es,
principalmente, la de un facilitador. Es quien organiza la reunión, modera las
conversaciones y controla los tiempos. Pero ahí, acaba su alcance. No olvidemos
que este no es un cargo de jefe y que se encuentra en el mismo nivel que los
demás miembros del equipo. El scrum master debe fomentar que cada participante
se dirija, en todo momento, a sus colegas, manteniendo una comunicación directa
y fluida. Porque el scrum diario se trata de sincronizar con el equipo y generar
planes de acción, no de rendir cuentas. Es más, si bien es deseable que el scrum
master, al igual que todos los que participan en el proyecto asista al scrum
diario, en el caso de que no pueda, la reunión debe celebrarse sin ningún
impedimento. De hecho, un buen scrum master debe incentivar este tipo de
conductas donde el equipo se autogestione a tal punto que no necesite que nadie
organice o modere las reuniones y actividades. Sobra decir que los 15 minutos de
tiempo no están escritos en piedra y que la flexibilidad lo es todo. Dependiendo de
cada equipo y del número de integrantes, tendremos casos donde se tardará más o
menos. Lo importante aquí es asegurarse de que todos los miembros
participen, que tengamos una radiografía clara del panorama de trabajo para cada
día, que se detecte cualquier obstáculo que impida cumplir con los objetivos y que
se obtenga como resultado un plan de acción para trabajar durante el día. Una vez
que cumplamos con estos requisitos mínimos, el scrum master puede dar por
terminada la reunión. Y, dado el caso, sugerir organizar reuniones secundarias para
hablar de temas específicos. Otra de las tareas del scrum master durante el scrum
diario es guiar y arbitrar cualquier diferencia en el abordaje de un problema. Y
hago énfasis en la palabra arbitrar porque el scrum master no es un juez que
decide el veredicto final. Su tarea aquí es aplicar el conocimiento que tiene del
equipo y sus miembros 

El scrum master durante la planificación del sprint

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Al igual que en el scrum diario, el scrum master es quien se encarga de organizar la
reunión para planificar el siguiente sprint, buscando un espacio para que se ejecute
sin interrupciones y distracciones. Durante la planificación del sprint, la función del
scrum master es la de guiar, arbitrar y generar un entorno donde el equipo pueda
compartir sus ideas y seleccionar las tareas que se van a trabajar en el próximo
sprint. La actitud del scrum master no debe ser pasiva y limitarse a calendarizar el
evento. Al ser un miembro más del equipo, tiene la responsabilidad de conocer el
estado actual del proyecto y el contexto de cada tema que se discute. Durante este
evento, el scrum master y el equipo colaboran en varios frentes. Por un lado, debe
trabajar con el product owner ayudándole a establecer los ítems del product
backlog, delimitar su alcance y, de ser necesario, adaptarlos a las condiciones y
recursos actuales. Debe guiarle para que comprenda el valor de crear ítems claros,
detallados y de fácil comprensión para que los desarrolladores puedan crear un
producto de calidad con la menor cantidad posible de errores o confusiones. Por
otro lado, le ayuda al equipo en varios aspectos. Por ejemplo, a brindarle
herramientas a los desarrolladores para que se comprometan a realizar una carga
de trabajo sostenible durante el sprint. Ni muy poco trabajo para que se
desperdicien recursos, ni tanto como para que se exijan demasiado. Una forma de
hacer esto es usar observaciones empíricas para comparar y estimar esfuerzo con
respecto a sprints anteriores. Pensemos que estamos en una reunión de
planificación y los desarrolladores quieren comprometerse a realizar tres tareas de
alta complejidad, pero no están seguros si eso puede ser riesgoso de cumplir. El
scrum master les puede ayudar pidiéndoles que analicen el trabajo que se
requiere para terminar esas tareas y lo comparen con otros momentos en que se
realizaron procesos similares. Seguidamente, les pide que se cuestionen temas
como: ¿Cuánto tiempo les tomó resolver en cada caso? ¿Qué diferencia hay entre
ambas situaciones? ¿Qué tan confiados se sienten de lograrlo en un tiempo
similar? Esto genera un intercambio de ideas entre los desarrolladores, que les
permite, finalmente, sentirse confiados en tomar esas tres tareas para el sprint
actual. Este tipo de dinámicas le deja libertad total a los desarrolladores para
aplicar su conocimiento técnico y decidir el mejor camino para implementar el
trabajo de sprint, mientras que el scrum master guía sin interferir en estas
decisiones, 

El scrum master durante la revisión del sprint

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
A diferencia de otros eventos de scrum en los que el scrum master  tiene un papel
destacado y muchas veces central, durante la revisión del sprint pasa a un segundo
plano. Durante esta reunión la función del scrum master es principalmente el de
moderación y observación de los tiempos, manteniendo todas las participaciones
acotadas y dentro de el asunto que les corresponde, mientras observa que la
reunión se encuentre en el rango correspondiente de tiempo. El tiempo que se le
asigna a la revisión del sprint depende de su duración. Así, un sprint de un mes
tiene como tope una duración de cuatro horas, uno de dos semanas, de dos
horas y el de una semana, solamente una hora. Es un error típico que el scrum
master tenga instintivamente la tendencia a dominar la reunión, pero es crucial que
durante la revisión del sprint el foco se mantenga en el producto, siendo
usualmente el product owner y los desarrolladores quienes protagonizan en esta
reunión. Algunas tareas que puede realizar el scrum master para esta reunión
son: facilitar información complementaria para los asistentes y asegurarse que
todos tengan contexto de lo que se está realizando, por ejemplo, enviarle por
adelantado a los asistentes permisos de acceso, documentación o materiales
necesarios para comprender las funcionalidades que se van a mostrar durante la
revisión. Aunque no es necesario, una buena idea para intervenir es mencionar los
principales logros, aciertos y descubrimientos realizados en el sprint o destacar el
rol de algún miembro del equipo de desarrollo que aportó de forma especial
durante este ciclo; aspectos que pueden aportar mejor contexto al avance del
producto y al esfuerzo de los desarrolladores. También se pueden presentar
indicadores clave que impactan el producto, como el efecto de las mejoras, tales
como la reducción del tiempo de la carga de un sitio web o la disminución de
costos de producción y, de ser posible, enviar esos datos a los asistentes para que
tengan un punto de comparación con los resultados de las siguientes
iteraciones. Estos pequeños datos adicionales ayudan a que se genere
visibilidad sobre aspectos del trabajo que agregan valor al producto, pero que en
ocasiones pasan desapercibidos.

El scrum master durante la retrospectiva

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Durante la retrospectiva, el rol principal del scrum master  debe ser, como en todos
los casos, el de facilitar, guiar y liderar, pero durante la retrospectiva, el enfoque va
hacia darle al equipo herramientas para que identifique puntos de
mejora. Recordemos que entre las responsabilidades del scrum master se
encuentra, justamente, la de hacer que el equipo sea más efectivo, y si tomamos en
cuenta que el objetivo de la retrospectiva es, justamente, buscar formas de ser más
efectivos, se puede ver claramente lo relevante que es este evento. Aquí, como
preparación previa, debe llegar con un profundo contacto con el equipo y su
contexto, conocer la realidad de cada participante y el trabajo realizado durante el
sprint. Para ello, habrá tenido reuniones individuales con los miembros del
equipo y escuchado lo que ocurre en las diferentes reuniones del sprint. Con toda
esta información, puede aportar su capacidad de análisis para encontrar detalles
que el equipo pase por alto y usar sus dones de liderazgo para mantener un
espacio seguro donde predomine la búsqueda de soluciones y el espíritu de
grupo. No olvidemos que la retrospectiva no es una rendición de cuentas. El o la
scrum master debe alejarse del rol de la autoridad y mantener esa relación de
iguales con el equipo para generar confianza y seguridad. La retrospectiva es un
proceso de autoanálisis donde se trata de sacar a la superficie las situaciones que
no han funcionado bien durante el sprint, los problemas que necesitan solución y
cualquier situación que requiera atención. Esto lo debe hacer en un tono
conciliador, constructivo y sin poner énfasis en buscar culpables. Sin embargo, un
scrum master debe ser asertiva en todo momento y de ser necesario señalar
concretamente el problema que necesita solución. Durante la retrospectiva, su
papel es de dejar un espacio al equipo para que haga un autoanálisis. Solo cuando
encuentra problemas que el grupo no ha mencionado es que debe darles
visibilidad. En esta misma línea, también es relevante poner atención a la detección
de patrones positivos y negativos. El scrum master tiene una muy buena
perspectiva al estar fuera del proceso de desarrollo, pero trabajando con él muy de
cerca para detectar la aparición de estos patrones. Cualquier situación que, de
alguna forma, 

Qué es un product owner

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Ser product owner o propietario de producto es una de las responsabilidades de
scrum que supone trabajar en conjunto con un scrum master y los
desarrolladores en la creación de productos y servicios. Como su nombre lo
sugiere, esta persona tiene una vinculación más fuerte con el producto y vela por
su resultado final. Pero es importante aclarar que, aunque la traducción al
español de owner es la de dueño o propietario, el término no implica
propiedad, sino que se refiere a una relación de compromiso y liderazgo con el
producto. Un o una product owner, entonces, no es la persona que paga el
proyecto o el dueño de la empresa, sino quien tiene un conocimiento profundo de
lo que se está creando y sus usuarios, y que usa esta información para buscar
nuevas formas de mejorar el producto en todas sus dimensiones. La
responsabilidad principal del product owner es la de maximizar el valor del
producto Esto lo logra capturando las necesidades de los usuarios, los intereses de
negocio y el objetivo, recopilando toda esta información e incluyéndola en el
product backlog con todas las partes y funcionalidades que espera que tenga el
producto. El product owner trabaja en equipo con los desarrolladores para
transmitirles toda la información necesaria para que conviertan esa visión en una
realidad. Para darte una idea de la relación entre estos roles, podemos imaginar a
una product owner como la arquitecta de un edificio. Ella es quien conoce a fondo,
el concepto completo del edificio, sus materiales y objetivos. Así diseña planos para
todas sus áreas pensando en el uso que le dará a cada una de ellas, y el efecto que
tendrá el edificio como un todo en la ciudad en que se construye. El product
backlog de un proyecto scrum es el equivalente al plano de el edificio en este
ejemplo. Al igual que una arquitecta, por más que inspeccione el proyecto 

Funciones y características de un product owner

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
El product owner debe tener un conocimiento profundo para delinear la ruta por la
que desea dirigir el producto y canalizar todas las voces y necesidades
relevantes para incorporarlas en este proceso. Para ejercer este rol, se necesita una
persona con ciertas habilidades, como apertura, instinto de negocios y, en
particular, habilidades de comunicación. El o la product owner necesita mantener
una política de apertura y disponibilidad con su equipo para que puedan contar
con él o ella a la hora de aclarar sus dudas, escuchar sus comentarios o enriquecer
el producto con estas interacciones. El instinto de negocios es una habilidad que le
ayuda a comprender el contexto de su producto y traducirlo en
valor, contemplando variables como el mercado, sus usuarios o la
competencia. Así, el product owner se ajusta y adapta para que cada sprint tenga el
máximo impacto posible. Las habilidades de comunicación son un factor crucial
para esta función porque debe mantener muchos canales abiertos. Por un lado,
debe escuchar al equipo, pero por el otro tiene que prestar atención a las partes
interesadas del proyecto o los stakeholders, que pueden ser clientes, juntas
directivas, grupos de inversores u otro departamento de la empresa. Todos ellos
pueden aportar ideas y solicitar que sus intereses estén representados en el
producto. El product owner aplica su criterio para escuchar todas esas voces, pero
se mantiene fiel a su misión y al objetivo del producto. Un buen product owner
muestra compromiso con el proyecto, haciendo lo que sea necesario para tener el
mejor producto posible. Esto implica una estrecha relación de confianza con el
equipo para que le aporten sus experiencias y conocimientos técnicos, además de
investigar y profundizar sobre las últimas tendencias y el alcance de su producto. 

Interacción del product owner con los desarrolladores

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Dentro de un equipo scrum, el product owner debe informar y guiar al
equipo, además de trabajar estrechamente con sus compañeros para concretar
juntos los objetivos del sprint. Para usar una metáfora, si el proyecto en el que se
trabaja fuera una escultura, el product owner sería la mente y los ojos del
artista, pero los desarrolladores son la mano y el cincel con el que se talla el
mármol. Son dos caras de la misma moneda y tanto product owners como
desarrolladores se necesitan mutuamente para terminar la obra. El product owner
debe tener clara su visión del proyecto y estar comprometido con esta y con los
objetivos de producto para poder alentar, motivar y transmitir asertivamente sus
ideas al equipo y asegurarse así de que se obtendrá una copia fiel de los conceptos
plasmados en el product backlog. El product backlog es la única fuente del trabajo
de los desarrolladores, o sea, que todo lo que se incluya en el sprint backlog debe
obtenerse de allí. Al ser el product owner quien prioriza y controla el product
backlog, sus acciones tienen una influencia determinante en el trabajo de los
desarrolladores. Sin embargo, y esto es importante recordar, los desarrolladores a
su vez tienen control total sobre el objetivo del sprint y los ítems que forman el
sprint backlog. Nadie puede obligarlos a tomar más o menos de lo que consideren
factible según su criterio técnico y autoconocimiento de la capacidad de avance del
equipo. Es común que se genere una dinámica en la que el product owner vela
únicamente por el producto y presione a los desarrollores para aceptar la mayor
cantidad de trabajo posible, mientras que estos últimos presionen para reducir esta
carga al mínimo. Este tipo de dinámica debe evitarse a toda costa porque ambas
partes son miembros del mismo equipo. El product owner no debe presionar por
deadlines extremos ni sobrecargas de trabajo, 

Interacción del product owner con el scrum master

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
El product owner y el scrum master son dos de las responsabilidades de scrum que
comparten más similitudes. Ambos necesitan tener un conocimiento profundo del
marco de trabajo, desarrollar excelentes habilidades de comunicación y poseer una
dosis alta de empatía para comprender a las otras personas. Ambos tienen un rol
de liderazgo dentro del equipo, aunque sus enfoques y objetivos son
distintos. Precisamente por esa diferencia de enfoque, es que se debe trabajar para
prevenir que ambos roles generen una relación de competencia o
antagonismo. No olvidemos que, en scrum, todos somos miembros del mismo
equipo y no existen niveles jerárquicos. A pesar de que estos dos roles tienen un
gran protagonismo y liderazgo, ninguno es jefe del otro. Justamente por eso,
existen las responsabilidades. Cada persona se rige por su responsabilidad
asignada y las tareas derivadas de ella. La principal y más importante diferencia que
existe entre el product owner y el scrum master es su enfoque. Mientras que el
primero lo hace en el producto, el segundo se aboca a los procesos y el
rendimiento del equipo. El product owner puede ayudarse del scrum master para
que le proporcione guía y contexto al momento de definir o refinar el objetivo del
producto, aprovechando su experiencia y conocimiento ágil. Sobre esa misma área,
con respecto al product backlog, si bien es cierto que el product owner es el
responsable de este artefacto, no quiere decir que sea la única persona que puede
aportar y menos aún que las intervenciones sean infalibles. La experiencia del
scrum master puede ser muy útil para aprender o mejorar la calidad de los ítems
del backlog, en especial, en las primeras etapas del equipo o cuando un product
owner comienza a trabajar en un nuevo proyecto. Cada equipo scrum trabaja
diferente y la ayuda del scrum master puede ser útil para reducir la curva de
aprendizaje sobre los detalles particulares. Tanto en el desarrollo de ítems del
product backlog como en sesiones de planificación, el scrum master aporta su
conocimiento profundo del equipo, sus ritmos, habilidades y personalidades. Todo
esto puede ser de gran ayuda a la hora de incorporar nuevas
funcionalidades, planificar sprints y aprovechar al tope los recursos disponibles
para alcanzar objetivos. 

El product owner en el scrum diario

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Al igual que todos los miembros del equipo, el product owner está invitado a asistir
al scrum diario para conocer el avance del proyecto y sincronizar esfuerzos con
todos los participantes. El scrum diario es una reunión para que los desarrolladores
puedan planificar y adaptarse según las condiciones actuales, así que técnicamente
la presencia del product owner es opcional. Sin embargo, si está trabajando en un
ítem que requiere aclaración o modificaciones, el product owner debe
participar como un desarrollador más. Esto es así porque la mayor parte del trabajo
del product owner viene del product backlog y sus ítems. Para el momento en que
se desarrolla el scrum diario, todas las tareas relacionadas con el sprint ya debieron
ser discutidas y aclaradas durante la reunión de la planificación del sprint. Al
menos, eso es lo ideal, pero no olvidemos que en scrum trabajamos con problemas
complejos, llenos de incertidumbre. Esos escenarios perfectos ocurren raras
veces. Aunque no se encuentra en la obligación estricta de asistir si no esta
participando en una tarea, sí es fundamental que se presente con frecuencia; por
esa razón, en mis equipos, le recomiendo al product owner que, salvo que tenga un
conflicto en agenda, participe de esa reunión, así sea que solo pase a
saludar. Como solo tarda 15 minutos, asistir requiere de un esfuerzo mínimo, pero
trae muchos beneficios para los intereses del product owner, porque le permite
estar al tanto del pulso del proyecto, conocer cuáles son los posibles
riesgos, refinar ítems y aclarar cualquier duda que el equipo pueda tener durante el
desarrollo de una nueva funcionalidad. No importa lo bien redactada que esté una
nueva funcionalidad y lo bien delimitado que esté su alcance o el tiempo que se
dedicó para analizarla durante la planificación, 

El product owner durante la planificación del sprint

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
La planificación del sprint es una reunión crucial para todo el equipo y en ella se
requiere la presencia del product owner y su liderazgo. Al ser la persona
responsable de maximizar el valor del producto y de la gestión del product
backlog, esta reunión de planificación tiene particular relevancia para este
rol. Antes de asistir a la reunión, se necesita una preparación previa, examinando y,
de ser necesario, replanteando el objetivo del producto. Con un objetivo claro en el
mediano y largo plazo, el siguiente paso es usarlo como guía para priorizar los
ítems del product backlog, dejando en los primeros lugares los ítems que cumplen
con dos condiciones: son los que más valor agregan al producto y los que más se
apegan al objetivo del mismo. Al final del product backlog, quedarán los ítems que
más se alejan de esos dos criterios. De esta forma, al llegar a la planificación del
sprint, el equipo cuenta con una visión clara de los ítems a los que deben darle
prioridad durante el ciclo de trabajo que inicia. Parte de ese trabajo previo también
incluye un proceso que, aunque consume tiempo, es crucial para el equipo, y es
asegurarse de que todos los ítems del backlog, o al menos los que se encuentran
ubicados en la mayor prioridad, estén redactados correctamente. Comprobar que
incluyen información clara y detallada, que toman en cuenta posibles
dependencias y, en particular, que tienen claramente definidos los objetivos,
efectos en el producto y criterios de aceptación. Estos datos serán la guía que se
utilizará para ejecutar las pruebas de control de calidad y también para que las
personas encargadas de implementar la tarea tengan claros cuáles son los
parámetros para implementar una mejora. Una vez iniciada la reunión de
planificación, el product owner debe practicar sus habilidades de
comunicación, compartiendo con el equipo su estrategia y detallando por qué este
sprint es valioso, la importancia de las metas trazadas para agregar valor al
producto y procurando transmitirles su visión. Juntos, todos los miembros del
proyecto tomarán esa visión y la van a concretar en el llamado «objetivo del
sprint», que será el foco en el que se va a trabajar en este ciclo. Todos los ítems
que se trabajen aquí deberían estar, en lo posible, alineados. Cuando se determina
el objetivo, el grupo pasa a seleccionar las tareas con las que consideran que
pueden comprometerse durante el sprint y aquí, aunque el product owner 

El product owner durante la revisión del sprint

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Durante la revisión del sprint todos los participantes del proyecto se reúnen para
examinar y probar los avances y logros de la última iteración. Aunque la guía de
scrum deja muy claro que los objetivos de este evento son inspeccionar los
resultados del sprint y buscar adaptaciones futuras, deja el formato a criterio del
equipo. Siendo así, aprovechemos esta lección para hablar de cómo es una
revisión liderada por un product owner. Un escenario perfectamente válido y que
se ve con relativa frecuencia. En este caso, el product owner es quien guía los
temas de esta reunión y se encarga de revisar el objetivo del sprint y todas las
tareas en las que el equipo trabajó durante este periodo. Puede también
mencionar junto a cada nueva funcionalidad cuales el valor que busca aportar al
usuario, y hablar desde su perspectiva de producto cómo este cambio es valioso o
cómo interactúa con otras partes del producto para crear una mejora. En un
escenario como este podemos imaginar que estamos trabajando en una aplicación
móvil de entrega de comida a domicilio y una de las tareas de este sprint era incluir
la funcionalidad de capturar los datos de tarjeta de crédito del usuario, sin
necesidad de usar teclado o ninguna interacción directa con el cliente. El product
owner menciona esta tarea y qué se buscaba en ella. En este caso, evitar la
contaminación cruzada entres los clientes y quienes hacen la entrega, al mismo
tiempo que se realiza una transacción segura. Puede también invitar a uno de los
desarrolladores, hacer una demostración de la nueva funcionalidad en acción y así
aprovechar su conocimiento técnico para dar una explicación más profunda. La
demostración de un caso como este puede ser abrir la aplicación, buscar la sección
donde se encuentran las secciones de pago, utilizar la cámara del dispositivo para
capturar los números de una tarjeta de crédito. Luego mostrar cómo se procesa un
sistema de reconocimiento de caracteres y, finalmente, almacenar el número
digitalizado en la aplicación en un formato encriptado para evitar filtraciones de
datos. 

El product owner durante la retrospectiva

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
La retrospectiva es una excelente oportunidad para hacer una pausa por un
momento y reflexionar sobre lo que ocurrió durante el sprint que acaba de
concluir. Es común que el product owner no asista a la retrospectiva, que solo
estén representados el scrum master y los desarrolladores en esta reunión, con el
argumento de que son ellos quienes están detrás del avance que se consiguió
durante el sprint y quienes más se benefician de este espacio de autoanálisis y
adaptación. Sin embargo, según la guía de scrum, todos los miembros del equipo
scrum deben participar de la retrospectiva y muchos product owners aprovechan
esta ocasión para seguir enriqueciendo su visión del producto y conocer más a
fondo a su equipo. Gracias a la dinámica de la retrospectiva, el product owner
puede recopilar mucha información valiosa que en el futuro le permitirá crear
tareas de mejor calidad, tomando en cuenta las capacidades del resto del equipo y
su perspectiva única. Cuando en la retrospectiva se habla de aspectos que
funcionaron correctamente y de los logros que se alcanzaron durante el sprint, el
product owner puede extraer los puntos fuertes que tiene a su disposición y
también conocer cuáles fueron las tareas que redactó con mejor calidad para
poder replicar ese patrón. Por otro lado, a la hora de analizar los factores que
salieron mal, puede tomar nota de objetivos que tal vez eran demasiado
ambiciosos, que tenían dificultades para implementarse y, por qué no, de ítems del
backlog que estaban mal diseñados o redactados, que terminaron generando
problemas de comunicación. Pero el momento más valioso para el product
owner tal vez sea cuando el equipo scrum busca soluciones y sugerencias para
evitar que estos problemas se repitan o experimenta nuevas formas de trabajo para
ser más eficaces. Aquí puede descubrir toda una cantera de nuevas ideas, nuevas
formas de abordar problemas y mejoras que, tal vez, no se le habían
ocurrido. Como todo miembro de un equipo scrum, el product owner debe abrirse
a la misma dinámica del equipo y someterse a ese proceso de autoanálisis y crítica
constructiva, escuchar los comentarios y sugerencias que llegan desde el resto del
equipo y tomar nota de las posibles mejoras que podría incorporar al desarrollar
las siguientes etapas del producto. 

Qué son los desarrolladores

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Los desarrolladores son el motor de scrum.  Son las personas que hacen que toda la
planificación y las tareas se conviertan en un producto real y concreto. Están
conformados por un número variable de miembros. Sin embargo, se recomienda
manejar grupos pequeños, de unas seis a nueve personas. Los grupos demasiado
pequeños hacen que sea difícil desarrollar ese espíritu de equipo y
camaradería. Además, tienden a ser desiguales y, en casos extremos, terminan con
más personas supervisando que trabajando en el proyecto. Por el contrario, los
grupos con demasiadas personas presentan problemas de comunicación y
dificultades para manejar el flujo demasiado alto de información. En proyectos más
complejos que exijan más personas, se deben dividir los equipos en diferentes
proyectos o áreas y que cada uno de ellos trabaje de forma autónoma. Cuando se
trabajan muchos equipos dentro de un solo proyecto más grande, se puede
celebrar una reunión adicional después del scrum diario llamada el scrum de
scrums, donde luego de sincronizarse con su equipo, un miembro de cada grupo
asiste a esta reunión y actualiza a los demás sobre lo que está sucediendo en su
respectivo equipo. Dependiendo del tipo de proyecto, generalmente, los
integrantes del equipo tienen diferentes profesiones y áreas de conocimiento y
cada uno de ellos se concentra en las diferentes habilidades necesarias para llevar a
cabo el proyecto. Por ejemplo, para un proyecto que busca desarrollar un libro, se
necesitará un equipo de escritores, editores, diseñadores gráficos e incluso
fotógrafos para poder administrar las diferentes partes y contenidos que requiere
un libro. Lo mismo ocurre en un proyecto de software. En este caso, si bien es
cierto que la mayoría de los miembros posiblemente sean desarrolladores de
software, también es posible que se necesiten diseñadores y encargados de control
de calidad. Los roles del equipo no necesariamente tienen que ser estáticos y es
frecuente ver que los miembros cambien su función en diferentes sprints o etapas
del desarrollo del proyecto. Un encargado de control de calidad puede pasar a un
papel de desarrollo de software si está dentro de sus capacidades o, por ejemplo,
una diseñadora puede ejercer la función de control de calidad 
Funciones y características de los desarrolladores

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Los desarrolladores deben estar comprometidos en todo momento con los
estándares de calidad y profesionalidad más altos, ya que su objetivo debe ser
siempre que el producto resultante de cada sprint esté listo para ser distribuido y
utilizado por otras personas o por el público en general. Por esta razón, al inicio de
cada sprint, el equipo de scrum se compromete a cumplir con ciertos objetivos que
se convierten en su misión principal durante todo el sprint. Cada miembro del
equipo, trabajará día a día para hacer que estos objetivos se conviertan en una
realidad concreta dentro del proyecto. Una de las características más interesantes
que tiene Scrum, es lo mucho que fomenta la autoorganización e independencia
de los desarrolladores. Independientemente de quien sea el scrum master o el
product owner, nadie tiene autoridad para decirle al equipo cuándo o cómo
desempeñar una tarea. Ellos tienen total libertad para elegir su trabajo y la forma
de resolver los problemas, pero esta autodeterminación y libertad no son
gratis, requiere que los desarrolladores deban también, autorregularse, y que
partiendo del diálogo y la negociación entre sus integrantes, se elija la mejor
solución a un problema. También deben elegir el o los miembros que se
encargarán de implementar esa solución, basándose en sus
habilidades, disponibilidades, experiencia e intereses. Aunque cada uno de los
desarrolladores tiene su propia especialidad y ejecuta un rango de tareas dentro
del proyecto, la libertad y el talento multidisciplinario es muy valorado en scrum, y
por esta razón no se manejan subgrupos o distinciones de ningún tipo entre los
miembros. Por ejemplo, si se trabaja en un producto de software, se evita
subdividir a los desarrolladores en programadores y diseñadores, ya que en scrum
el grupo es mucho más que la suma de sus partes, y se debe buscar trabajar como
un conjunto unificado. Precisamente por eso, los desarrolladores deben ser
flexibles y adaptarse a cada uno de los retos que conlleva una iteración, y ninguno
puede estar férreamente comprometido con su rol o su forma de trabajo. Todos
deben estar preparados para intercambiar funciones y ayudar a cualquier
compañero 

Interacción de los desarrolladores con el product owner

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Un equipo scrum no sigue las órdenes de un jefe o una junta directiva.  Se alimenta
únicamente de los ítems del product backlog para hacer sus planes de
trabajo. Debido a que el product owner es la persona responsable de este
artefacto, las acciones del product owner afectan directamente el trabajo diario de
los desarrolladores. Para ellos, el product owner es quien traza la ruta que llevará el
proyecto y, por esto, deben poner especial atención a sus intervenciones, porque
comprendiendo su visión, pueden comprender mejor el producto en el que están
trabajando. El punto de encuentro, donde se encuentra el trabajo de los
desarrolladores con el product owner, es, como se mencionó ya, en el product
backlog. Aquí es donde, por un lado, los desarrolladores se alimentan de tareas por
realizar y, por el otro, el product owner crea nuevas funcionalidades para el
producto y pule las anteriores; un flujo de ideas constante que a través de trabajo y
esfuerzo se va convirtiendo, poco a poco, en una realidad. Por esta relación, los
desarrolladores deben atender y respetar el liderazgo que ejerce el product owner
sobre el rumbo del producto. Sin embargo, aunque el product owner es el
responsable de mantener y priorizar el backlog y también participa en conjunto
con el resto del equipo para la definición del objetivo de sprint, son los
desarrolladores quienes tienen la última palabra sobre el trabajo que se agrega al
sprint backlog. También tienen la última palabra a la hora de elegir cómo
implementar las soluciones y, aunque el product owner tenga un conocimiento
avanzado sobre las características solicitadas en cada tarea, son los desarrolladores
quienes deciden cómo se va a abordar este problema. Ese control siempre debe ir
acompañado de una actitud humilde, abierta y autocrítica para escuchar
sugerencias y experiencias que pueda aportar el product owner. Nadie tiene el
monopolio del conocimiento y lo importante es crear un producto de valor, sin
importar de dónde salen las ideas para llegar a ello. Cuando los desarrolladores
trabajan en la planificación del sprint, deben escuchar con atención al product
owner, 

Interacción de los desarrolladores con el scrum master

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Durante todo el proyecto, los desarrolladores colaboran codo a codo con el scrum
master. Ambas responsabilidades están estrechamente relacionadas y dependen
mutuamente para poder trabajar. Es muy común y hasta deseable que se desarrolle
esa relación de camaradería y confianza entre ambos para que el scrum master se
vea como lo que es, un miembro más del equipo. El scrum master es un líder y
mentor y constantemente comparte su conocimiento sobre scrum para mejorar los
procesos, hacer que el equipo sea más eficiente y para mantenerse enfocados en
generar el mayor valor posible en cada incremento de producto. Desarrolladores y
scrum master deben crear una relación de confianza mutua, donde ambas partes
confían en las capacidades profesionales de la otra. Por un lado, los
desarrolladores deben confiar que el scrum master está allí para ayudarles, que
pueden comunicarse directamente y que tienen un espacio seguro para expresar
cualquier preocupación sobre el producto o posibles riesgos para entregar a
tiempo que puedan detectar. Por otra parte, el scrum master también debe
confiar en las capacidades profesionales de los desarrolladores, evitando cuestionar
sus decisiones técnicas o su compromiso con el proyecto. En ambos casos, en
scrum, se asume que todos los participantes dan lo mejor de sí para crear un
producto que genera valor para el usuario. Nadie debe cuestionar temas como las
horas trabajadas o el esfuerzo de un compañero de equipo. Las métricas y el
cumplimiento de objetivos al final del sprint son las que responden a esas
dudas. Muchas veces, el scrum master puede aportar valor al equipo a partir de su
experiencia o de la observación empírica del avance histórico del equipo. Este
punto de vista único puede ayudar a los desarrolladores a detectar algo que
habíamos pasado por alto o que ya ocurrió un problema muy similar en el
pasado y utilizar las experiencias anteriores para solucionarlo. Si nada de esto
funciona, el scrum master siempre puede guiar a los desarrolladores para que,
basados en esa evidencia empírica, 

Los desarrolladores durante el scrum diario

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Durante el scrum diario, tenemos la oportunidad  de sincronizarnos o detectar
oportunidades y obstáculos. Así que los desarrolladores deben asistir y participar
en esta reunión siempre y ausentarse solo por razones extraordinarias. En esta
reunión, los desarrolladores son los que generan el material principal de la
conversación. Tradicionalmente, la estructura sugerida para esta reunión era que
cada miembro del equipo tomara la palabra para actualizar a todos los
participantes sobre su avance respondiendo tres preguntas: ¿cuál fue el avance
conseguido el día de ayer? ¿Que se planea conseguir el día de hoy? Y si encuentra
algún impedimento para avanzar durante este día. En la versión más moderna de
scrum, si bien es cierto este formato no está prohibido ni mucho menos, se deja en
libertad total al equipo scrum de elegir la forma que mejor les
funcione. Actualmente, la prioridad en esta reunión, más que pasar lista a los
miembros del equipo y preguntar qué están haciendo, es la de crear un plan de
acción para avanzar de la forma más eficiente posible. Por ejemplo, un par de
desarrolladores encargados de liderar alguna tarea pueden indicarle al resto de los
miembros del equipo sobre el estado de su avance y las dificultades que detectan
que pueden afectarles durante el día. El equipo completo aporta ideas y
experiencias para buscar soluciones que pueden incluir, por ejemplo, moverse a
otra tarea que tenga menos obstáculos, asignar más desarrolladores a un área o
pedir ayuda a expertos externos. Lo importante es no quedarse de brazos
cruzados y siempre tener un plan para avanzar. Durante este evento, también es
importante que aclaremos todas nuestras dudas en las tareas que estamos
ejecutando, porque la descripción o requerimientos no estén claros o porque en el
camino hemos hecho nuevos descubrimientos que afectan el desarrollo o el
contexto original según fue conceptualizada esta tarea. Por otro lado, conforme
trabajas en un proyecto, lo vas conociendo más a fondo y, muchas veces, los
desarrolladores, gracias a su conocimiento técnico, pueden detectar potenciales
errores que aún no afectan el producto, pero que pueden hacerlo en un futuro
inminente. Estos problemas potenciales también deben ser mencionados al equipo
a manera de observación o comentario 

Los desarrolladores durante la planificación del sprint

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Antes de llegar a la reunión de planificación del sprint es buena idea que todos los
miembros del equipo dediquen un tiempo individual para leer todas las tareas que
se van a debatir. Así pueden identificar errores, problemas y consultas
previamente, y agilizar el flujo de la reunión y en ella, se acordarán las tareas que
se completarán durante el siguiente sprint. Los desarrolladores deben mantener
una actitud proactiva a la hora de comentar, sugerir y hacer todas las consultas
necesarias para tener clara la implementación de cada tarea. Aunque no es un
requisito de scrum, al examinar las tareas que se van a ejecutar durante el sprint, en
mi experiencia, he tenido muy buenos resultados con una simple medida. El equipo
completo debe dedicar aproximadamente 30 minutos para evaluar cada
historia. Examinar sus dependencias, aclarar todas las dudas, y en algunos casos,
incluso discutir cuál puede ser la implementación, para que todos tengan claro el
nivel de dificultad necesario. Transcurrido este tiempo, todos están preparados
para hacer una estimación del trabajo, de acuerdo con los cálculos y el consenso
interno del equipo se elegirán las tareas para el sprint. Es importante mantener
siempre presente que aunque el product owner manifieste sus sugerencias para las
tareas que quisiera elegir, son únicamente los desarrolladores quienes deciden de
forma unilateral las actividades con las que se van a comprometer durante esta
iteración. Siempre alineados con el objetivo del producto, y la debida priorización
del product backlog que realizó previamente el product owner. Este acuerdo lo
deben hacer basándose en el nivel de dificultad que presenta cada tarea. El equipo
scrum y, en particular, los desarrolladores deben responsabilizarse de la mayor
cantidad de tareas posibles pero siempre siendo fiel al plazo de entrega. Nunca
deben arriesgarse a entregar más de lo que consideran posible cumplir en el plazo
de la iteración. Si no se logra un consenso a la hora de elegir los objetivos de
estimar la dificultad en la tarea o en el caso de que los miembros del equipo
tengan diferencias técnicas sobre la implementación de una solución, deben acudir
al scrum master para que arbitre y guíe a los desarrolladores a tomar la decisión
más apropiada basados en la evidencia empírica.

Los desarrolladores durante la revisión del sprint

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
La revisión de un sprint es una actividad  donde se examina el avance del equipo, el
efecto de su esfuerzo aplicado en el producto y cómo esto puede abrir nuevos
caminos. Para este evento, deben asistir todos los miembros del equipo scrum, en
particular, los desarrolladores, que deben estar preparados para mostrar nuevas
funcionalidades, dar contexto sobre temas técnicos o, sencillamente, aportar con
nuevas ideas. El formato de la revisión lo decide cada equipo, pero, usualmente, ya
sean los desarrolladores involucrados con las nuevas funcionalidades o el mismo
product owner hacen una revisión detallada sobre las nuevas mejoras que se
introdujeron en el producto durante el sprint que finaliza. En este evento, los
desarrolladores deben mostrar una actitud atenta y participativa, listos para aclarar
cualquier duda o demostración sobre los avances del producto. En mi experiencia
personal, procuro que, al menos, un día antes los desarrolladores tengan una
sesión rápida de preparación previa para la demostración y así garantizar que todo
funcione en las condiciones esperadas. También este es un buen momento para
verificar que quienes se encargan de la prueba tengan todo lo que necesitan y
generen un plan de acción para saber cómo comunicar el avance, mostrando en
detalle todas sus capacidades e impacto sobre el producto. Unos minutos antes de
que se empiece la reunión, se recomienda tener todo preparado para que el
producto se pueda utilizar y se encuentre totalmente funcional, si es posible, hacer
una prueba rápida antes de que ningún problema distraiga a los asistentes y poder
abordar directamente el tema. Esto ayuda a detectar y evitar distracciones o
problemas derivados de factores externos. Si el producto necesita de una fuente de
energía eléctrica, verificar que tiene la capacidad de trabajar durante toda la
revisión o, si es un software que consume datos externos, asegurarse que estas
dependencias están funcionales también. Pensemos cómo podría ser la
interacción de los desarrolladores en un caso realista. Imaginemos que nuestro
proyecto consiste en una aplicación para una red social y queremos mostrar cómo
se implementó una nueva funcionalidad que le permite a los usuarios mantener
conversaciones privadas a través de mensajes instantáneos. Qué mejor que quienes
crearon estas funcionalidades para explicar su alcance con lujo de detalles a todos
los presentes. Así no solo pueden mostrar la aplicación de esta parte nueva del
proyecto, sino que también pueden mencionar los pequeños detalles que no se
notan a primera vista o la gama completa de funcionalidades implementadas. Al
finalizar la revisión del sprint, todos los presentes deben conocer a fondo las
nuevas funcionalidades y capacidades del producto. Esto, en muchos casos, cambia
o amplía el rango de acción del producto, lo que significa que pueden
agregar nuevas funcionalidades que aporten valor al proyecto. Precisamente, es así
como se debe cerrar la reunión, con los desarrolladores participando y escuchando
atentamente al product owner, y, en caso de que estén presentes, a los
stakeholders del producto, juntos, todos trazando las líneas y tendencias que debe
seguir el producto a partir de su actualización más reciente.

Los desarrolladores durante la retrospectiva

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
La retrospectiva es un momento de reflexión y autoanálisis que tiene lugar al final
de cada sprint y que puede ser especialmente útil para los desarrolladores. Esta
reunión también puede ser especialmente dura para ellos, en particular cuando no
se cumplen todas las metas con las que se comprometieron. Durante la
retrospectiva cada miembro del equipo puede compartir con sus colegas todas las
cosas que considera que funcionaron correctamente y los aciertos que
tuvieron. También se debe de hablar sobre lo que consideran que no funcionó tan
bien y no limitarse únicamente a hacer autorreferencias sobre los problemas de su
trabajo, sino que también tienen la opción de comentar los problemas encontrados
en el trabajo de sus colegas. Siempre se debe mantener un tono asertivo y
constructivo y señalar únicamente los problemas y nunca a las personas. El equipo
debe tener la madurez suficiente para evitar buscar culpables o
justificaciones. Cuando una crítica está dirigida hacia un miembro del equipo se
debe hacer de manera constructiva y quien la recibe nunca debe tomarla de forma
personal. El equipo se encarga de detectar los problemas, y todo desarrollo
humano está sujeto a ellos. Por eso cuando te ocurren a ti debes entenderlos como
una constante que se debe intentar prevenir todo lo posible, pero que es imposible
de eliminar. La principal acción que se debe de ejecutar en esta fase es encontrar la
raíz central de un problema, identificar las causas y asignar un responsable que
trate de solucionarlo. El objetivo de la retrospectiva es encontrar formas de hacer
que el equipo sea más efectivo y, de ser posible, crear planes de acción claros para
ello. Los miembros del equipo pueden aplicar un ejercicio de confianza con su
grupo y hablar abiertamente de sus propios errores, siempre comprendiendo que
eso es un espacio seguro y que un error no necesariamente significa una
terminación de contrato, por el contrario, el objetivo principal de esta reunión es la
autocrítica y el espacio para mejorar. El equipo debe mostrarse abierto, no solo a
escuchar comentarios y críticas constructivas, sino también a hacer modificaciones
y a aplicar nuevas técnicas o experimentar nuevas formas de trabajo para cumplir
con todos los objetivos del siguiente sprint.

Herramientas para gestionar proyectos scrum

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Scrum es un proceso que se centra en la simplicidad  y, como tal, se esfuerza por
utilizar pocas herramientas. La mayoría de los proyectos, no importa la
complejidad, se pueden trabajar perfectamente con solo un equipo
comprometido y aplicando correctamente los principios de scrum. Sin embargo,
siempre debemos tomar en cuenta el factor humano y el primer elemento que se
ve afectado por él es el product backlog, que es, básicamente, una lista donde
vamos a incluir todas las funcionalidades del proyecto basadas en un objetivo
común, llamado el «objetivo del proyecto». Y es fundamental que algo tan
valioso tenga algún tipo de respaldo para que no olvidemos sus
contenidos. Tradicionalmente y, de nuevo, para conservar esa simplicidad, el
product backlog se mantiene en cualquier rincón de la oficina, utilizando las
clásicas tarjetas autoadhesivas, que se han convertido en el emblema de los
proyectos ágiles. El product owner anota la nueva tarea en una tarjeta y la coloca
en un lugar físico, que se convertirá en el product backlog. Durante la planificación
del sprint, el equipo scrum elige las tareas, en este caso, representadas en tarjetas
autoadhesivas, y las mueve a una sección que se convertirá en el sprint backlog y
determinará el trabajo que se va a completar durante la iteración
actual. Finalmente, al terminar cada tarea, los desarrolladores van moviendo o
marcando las tareas acabadas. Estas tarjetas se utilizarán como una especie de
guion durante la revisión del sprint. El product owner va tomando una a una las
tarjetas marcadas como terminadas, las detalla y muestra con ayuda del resto del
equipo. Este sistema se utiliza muchísimo. Sin embargo, conforme se escalan los
proyectos y las tareas se vuelven más complejas, tiende a quedarse corto. Esto,
también, debido a que está sujeto a un entorno físico y no es accesible por equipos
que trabajan en modalidad remota o donde solo una parte o todo el equipo
trabaja desde Internet y no hay un lugar para guardar nuestras tarjetas
autoadhesivas. Para estos casos, tenemos programas que siguen los mismos
principios de las tarjetas, pero ofrecen más ventajas, como un espacio ilimitado
para detallar las tareas, incluir archivos adjuntos para explicarlas mejor o registrar
todas las conversaciones que se llevan a cabo sobre este tema para aclarar una
idea. Uno de mis favoritos, y no solo por su simpleza, sino porque tiene la opción
de uso totalmente funcional, es Miro, 

Buenas prácticas con scrum

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Un proyecto scrum está en constante adaptación  y siempre hay espacio para
mejorar. Aunque ya conozcas de memoria todas las reglas de scrum o lleves varios
años trabajando con este marco de trabajo, siempre hay pequeños detalles que se
escapan. Precisamente por eso voy a compartir contigo algunas de las buenas
prácticas que me han ayudado mucho a mejorar el rendimiento de los proyectos
en los que he trabajado. Empecemos con el proceso inicial de muchos
proyectos, que es la creación del product backlog. En este punto, el product owner
comienza a definir las primeras funcionalidades y sus requisitos para lo que será el
producto terminado. En muchos casos, este proceso arranca sin una meta
definida, principalmente basada en expectativas de cómo debe ser un buen
proyecto de este tipo, lo que en muchas ocasiones lleva a la creación de tareas
innecesarias o redundantes. Un buen punto de arranque para esta lista es crearla
después de definir el objetivo de producto, que es la proyección hacia el futuro que
tiene el product owner sobre este proyecto. Al tener clara y definida la meta final,
es más fácil comprender la ruta que se debe seguir para que el producto esté
terminado. Otro aspecto importante es lidiar con la deuda técnica. Ocurre cuando
encontramos algún problema en la funcionalidad del producto. Puede ser un error
de cualquier tipo y, sin importar cuándo se originó, en el momento en que se le
encuentra, pasa a la lista de problemas del producto. Esto no tiene nada de extraño
o problemático. Las personas somos falibles y todos los proyectos tienen
errores. Pero en el instante en que algo entra en esta lista, tenemos un problema
no resuelto y esto es lo que se conoce como una deuda técnica. Si dejamos que
estos errores se acumulen sin hacer nada por eliminarlos, la deuda crecerá y
posiblemente genere problemas más complejos. Por eso, una buena técnica scrum
es tratar de solucionar todos los problemas encontrados en el mismo sprint en que
se detectan y no acarrear problemas para el siguiente sprint. Otra buena práctica
viene al momento de la planificación del sprint, donde el equipo completo analiza
las tareas de las que se ocuparán en el siguiente sprint. En este punto, muchas
veces, por prisa o cansancio, los ítems del product backlog se examinan basándose
únicamente en su título y descripción. Esa es toda la información que se usa para
estimarlas, incluirlas en el sprint y, eventualmente, trabajar en ellas. Sin embargo,
no dedicarle un buen tiempo de revisión a una tarea puede llevarnos 

Siguientes pasos con scrum

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo

en el vídeo
Llegamos al final de este curso de los roles y responsabilidades de scrum.  Ya
conoces no solo la descripción de cada una de las responsabilidades sino la
filosofía que está detrás de cada una de ellas y cómo se relacionan entre sí durante
todos los eventos. A lo largo de este curso aprendimos que scrum es un
framework que te ofrece un marco para implementar diferentes técnicas y
métodos con total libertad y rango de acción. También descubrimos que aunque la
entrega constante de soluciones y el cuidado de los plazos es crucial, en scrum se
ve el proyecto terminado como una meta y se centra principalmente en el camino,
tratando de dedicar tiempo cada día a planificar, examinar, corregir y
principalmente adaptar. Scrum consiste en un camino de autoanálisis, trabajo en
equipo y constante adaptación y, si bien es cierto, que no tiene la capacidad de
garantizar que un proyecto sea exitoso, si se ejecuta con dedicación puede jugar
un papel clave en la evolución de un producto. Aunque scrum por definición es
simple, comprendemos ahora que su implementación exige madurar y puede
tomar un tiempo de adaptación y asimilación dentro de los miembros de un
equipo, es una semilla que debemos dejar crecer en nuestro proyecto. Si bien
scrum es totalmente intuitivo y no se necesita ninguna herramienta o programa
especial para ponerlo en práctica, toda ayuda es bienvenida. Así como tenemos
programas especializados para administrar proyectos, también existen programas
de capacitación de scrum que permiten especializarnos en sus diferentes roles. Si
deseas certificarte como scrum master, dueño de producto o como desarrollador
scrum, hay muchos sitios e instituciones que ofrecen este servicio; sin embargo,
solo existe un organismo oficial que emite la certificación aceptada en todas partes
del mundo, y es el Scrum Alliance. Si estás interesado en obtener un certificado, te
recomiendo que visites el sitio scrumalliance.org, donde podrás consultar los
programas, los horarios, la disponibilidad y los costos del proceso de
certificación. Adjunto a este curso podrás encontrar enlaces y materiales que
pueden ser un buen punto de partida para seguir aprendiendo sobre el maravilloso
mundo de scrum y la agilidad. Para mí ha sido un gusto acompañarte en este
proceso de aprendizaje, espero que sea el inicio de tu viaje por scrum. No dudes en
agregarme en tus redes sociales,