Presentación del curso “Scrum: Roles”

Hola, soy Carlos Solís, autor y desarrollador, y en este curso, vamos a trabajar
con los roles de Scrum. Posiblemente, ya conoces esta metodología ágilde
gestión de proyectos, que se ha convertido, prácticamente,en el estándar de
trabajo de incontables organizaciones y empresas. También, es probable que
sepas que Scrum es fácil de comprender y, en general, no toma mucho
tiempo comenzar a utilizarlo en un proyecto. Sin embargo, no se trata solo
de hacer reuniones cortas y definir plazos de entrega. La implementación
completa de Scrum requiere tiempo. Exige que cada integrante conozca a la
perfección su rol y el de los demás, para que mantengamos el proyecto
funcionando y sin fricciones. En este curso, aprenderás cuáles son las tareas
y los procesos que debe cumplir cada integrante del proyecto, y
analizaremos en detalle cada rol y su relación con los demás, a lo largo del
ciclo de vida de un proyecto,mientras seguimos profundizando en la filosofía
de trabajo de Scrum.

Qué es SCRUM y qué lo hace especial

SCRUM se autodefine como un marco de trabajo para productos
complejos. Y 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, y 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 con 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 vuelve infalible.Me ha tocado ver jefes que de pronto, leen un
artículo de SCRUM y creen que haciendo una reunión diaria de 15
minutos, mágicamente aumenta la producción, y de paso nos transportará
en el tiempo para presentar los proyectos atrasados con días de
anticipación. Pero 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. SCRUM consiste en un marco de trabajo. Una serie de procesos y
guías para que nosotros mismos encontremos los espacios para mejorar y
adaptar el trabajo hasta encontrar el camino que funciona mejor para cada
equipo. Parte de la popularidad de SCRUM es que tiene muy pocas
barreras. Para comenzar, no necesitas ningún software, carrera
universitaria, licencias o infraestructura; por lo que se adapta a cualquier
presupuestoy a organizaciones de cualquier tamaño. Los procesos de
SCRUM son fáciles de entender y comenzar a utilizar. Cualquier miembro
que se una a un equipo puede entender rápidamente la dinámica de las
reuniones y los roles. Pero que no te engañe esa facilidad,entender SCRUM
puede ser fácil, pero dominarlo toma tiempo. Porque siempre tiene un
ángulo nuevo por descubriry en el que hay que profundizar. Al ser un marco
de trabajo, SCRUM está totalmente abierto para que dentro de él se
apliquen diferentes técnicas de trabajosegún las preferencias y necesidades
de cada organización. Para finalizar, el objetivo central de SCRUM es
mantener un proceso constante de revisión, adaptación y mejora, hasta
encontrar el punto de equilibrio perfectopara 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. Por ejemplo, me ha tocado
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 tienenposibilidad de corregirlo.Considera la incertidumbre de un
producto como una apuesta, si no estás seguro 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,justamente, por eso tantas empresas lo adoptan.

El Scrum diario
De todos los rituales 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 framework de
trabajo,parte de una premisa muy sencilla: una reunión de 15 minutos en
total donde participan todos los miembros del proyecto y hablan de su
estatus actual. 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 trabajodonde el mismo
calendario te asigna una hora de duración, por defecto, y prácticamente, en
todos los casos terminamos tardando mucho más que eso,en el Daily Scrum,
tenemos apenas 15 minutos, de principio a fin. ¿Por qué tan poco
tiempo? Bueno, no es casual.Hay muchas razones detrás de ese límite de 15
minutos. El principal es mantener a los miembros del equipo concentrados y
no perder su atención. Todos, en algún momento, hemos quedado
atrapados en esas reuniones interminables. Sabemos por experiencia que
luego de 30 minutos prácticamente nadie está poniendo atención, y
dependiendo de la hora, algunos hasta comienzan a dormirse. Otra razón, 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.Durante la
reunión del Scrum diario vamos a tener un formato muy específico de
participación. Cada miembro del equipo de desarrollo debe tomar la
palabra, y mientras sus compañeros escuchan atentamente, actualizarles
sobre el estado actual de su trabajo. La intervención de cada miembro debe
responder a tres preguntas básicas: ¿Cuál fue mi avance el día de ayer? ¿Qué
estoy planeando hacer el día de hoy? ¿Qué problemas o bloqueos me
impiden avanzaren mis objetivos diarios? De esta forma, todos los asistentes
quedan sincronizados con el estatus actual del proyecto y en el caso de
proyectos más complejos, cuando todos los miembros saben qué hace cada
miembro del equipo, pueden planificar y coordinar sus tiempos de entrega o
próximos avances. El Scrum diario debe llevarse a cabo, de preferencia,
siempre a la misma hora y en un lugar con la menor cantidad de
interrupciones posibles. Si bien es imprescindible que los miembros del
equipoparticipen de este ritual, porque son quienes mantienenel
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 trabajosolo 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

El Sprint es la piedra fundamental de Scrum.Consiste en un bloque de
tiempo, durante el cual se desarrolla el proyecto. Es durante este período
que los miembros del equipocompletan su trabajo diario. El Sprint es la
unidad de tiempo cíclica con la que trabajamos en Scrum. El tiempo que
dura un Sprint es relativo a muchos factores, como la complejidad del
proyecto, el tipo de producto que se desarrolla, o las capacidades y el
número de integrantes del equipo. Como regla general, un Sprint tiene una
duración 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 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 el tiempo ayuda en casos
en que sea necesario hacer muchas pruebas de control de calidad o las
tareas comunes sean más complejas. Aunque es perfectamente normal
reducir el tiempo del Sprint, el máximo de un mes se debe mantener
intacto. Como todo en Scrum, hay varios motivos detrás de esa medida. Por
ejemplo, al mantener un máximo de un mes, se limita el grado de
complejidad del trabajo, y 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 un proceso individual y
separado del anterior. Por eso, antes de comenzar, debemos planificar
cuidadosamente y tener muy claro los objetivos principalesque deseamos
cumplir en este período. Por ejemplo, si estamos trabajando en un proyecto
de software, podemos definir como objetivo del Sprint, que sea posible crear
y administrar un perfil de usuario,y separar las diferentes tareas y partes de
su objetivo para ir cumpliéndolas a lo largo del Sprint. Al final del plazo,
debemos tener un producto terminado y listo para producción. Siguiendo el
ejemplo anterior, si el objetivo era un software que puede crear y
administrar perfiles de usuario, al finalizar el Sprint, esta nueva
capacidad debe estar totalmente operativa, sin errores, y lista para que
cualquier otra persona pueda utilizar. 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, 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. Por eso,
todo proyecto sin terminar maneja un nivel de incertidumbre donde pueden
ocurrir situaciones totalmente inesperadas. El objetivo del Sprint es, por un
lado, implementar el plan que desarrolle el equipo, pero manteniendo
períodos relativamente cortos de trabajo.También busca reducir al máximo
la incertidumbre y tener resultado rápido. Así, si las cosas salen
mal, solamente se pierde, como máximo, un mes de trabajo, y es posible
rectificar inmediatamente.

La planificación del Sprint

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 que terminaste la carrera? En Scrum tenemos un evento llamado la
planificación del sprint, que es el momento en que se delimita cuál será el
plan de acción del equipo en la siguiente iteración del proyecto. Debido a
que los sprints se siguen inmediatamente uno luego 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 nuevo sprint, ya todo está
debidamente planificado y todos los miembros están listospara 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 y proporcional de
aproximadamente dos horas por semana de duración del sprint. En otras
palabras, para un sprint de dos semanas, el límite es de cuatro
horas,mientras que el límite máximo es de ocho horas para un sprint de un
mes. 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 o
la lista de producto, que es una lista, donde se incluyen todos los requisitos
y funcionalidadesque 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 backlog.Antes de comenzar
a trabajar en la planificación, el equipo debe plantearse dos preguntas
básicas: ¿qué puede hacerse en este sprint? y ¿cómo se conseguirá acabar el
trabajo seleccionado? Para responder a la primera pregunta, se contempla el
estado actual del proyecto, los recursos disponibles o las variables del tipo
temporal que pueden afectar el producto, como estaciones o festividades. La
segunda pregunta necesita un análisis detallado de la tarea.Requerimientos
técnicos, las dependencias, los posibles obstáculos y concretar la
implementación. Vamos a imaginarnos cómo sería la planificación del
sprint en un mundo real. Supongamos que estamos desarrollando un
proyecto de software bancarioy en el backlog tenemos requerimientos como
permitir transferencias entre cuentas, la capacidad de revisar mis saldos,la
autenticación en dos pasos, el soporte para criptomonedasy la mensajería en
tiempo real.El equipo se reúne y luego de revisar el 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 saldoestán relacionadas y aportan funcionalidad al objetivo del
sprint, también son elegidos.Los demás requerimientos del backlog pasan a
un segundo plano, en espera de ser seleccionados en otro sprint.Una vez
elegidas las tareas que se van a completar, se analiza la factibilidad técnica y
se acuerdan los detalles de implementación y los recursos, tanto humanos
como técnicos,necesarios para finalizar cada tarea. Al acabar el proceso de
elección de un objetivo y la selección de las tareas necesarias para
cumplirlo, el equipo tendrá una perspectiva general y las metas claras para
poner las manos a la obra en el instante en que inicie el sprint que se ha
planificado.

La revisión del Sprint

Durante el sprint, el equipo de trabajo se encarga de implementar todas las
tareas y los objetivos que fueron definidos durante la etapa de
planificación. En la revisión del sprint es donde vamos a mostrar los
resultados concretos de todo este trabajo y planificación. 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.Aquí sobran los PowerPoints,
los diagramas de flujo y las cartas Gantt. Esta es una reunión para que los
hechos concretos sean los que hablen por el equipo. En la revisión del sprint
vamos a hacer un demo del proyecto. Pero no se trata solo de mostrarle al
mundonuestra aplicación o producto y esperar los aplausos. Aquí, vamos a
hablar de cada tarea realizada y procederemos a contrastar los cambios, de
manera que cada tarea esté vinculada a un proceso de demostración en el
mundo real.Por ejemplo, supongamos que estamos creando un
softwarepara 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 debe comenzar, mencionando la
tarea que se quiso abordar. Por ejemplo, el flujo de los pedidos. Una vez
detallados brevemente los requerimientos, se procede a explicarle al resto
de los presentes cuáles fueron los cambios que se aplicaron en el
sprint. Supongamos que acá se agregó un sistema de mensajería
instantánea entre los meseros y la cocina para hacer más eficiente el proceso
de pedidos. Así que para demostrar 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. También, durante la
demostración se puede mencionar los retos o problemas encontrados en el
sprint y cómo se solucionaron.Supongamos que nuestro equipo de software
para restaurantes tuvo problemas con el sistema de propinas, porque luego
de implementarlodescubrieron que no en todos los países se calculan
igual, así que, se decidió incluir un sistema de geolocalizaciónenlazado a una
tabla de opciones que calcula la propina correspondiente para cada país.Y, al
igual que en el caso anterior, se procede a mostrar el nuevo
avance simulando diferentes ubicaciones geográficas y mostrando cómo
reacciona el sistema calculando propinas distintas de acuerdo a la región en
que se encuentre.Una vez terminada la revisión de los objetivos y tareas
cumplidas, en conjunto con su correspondiente demostración funcional, se
procede a analizar y proyectar nuevas funcionalidades y posibles nuevas
tareas en las cuales trabajar gracias al avance. En muchos casos, la revisión
del sprint nos permite descubrir nuevas opciones y capacidades que antes
no eran posibles por temas técnicos, prácticos o funcionales.

La retrospectiva finalizado el Sprint

La mejora y 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 equipopara analizar los resultados, evaluarse a sí
mismo, y, principalmente, buscar formas de mejorar. Tal como las otras
reuniones que tenemos en Scrum, la retrospectiva es una reunión larga, de
un tiempo variable, pero limitada a tres horas máximo para un esprint de un
mes. Y 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 clarotodo lo que ocurrió durante el esprint anterior y tenemos
la oportunidad de identificar todos los errores y aciertospara 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. Es importante mencionar que una
reunióndonde 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 más alejado al objetivo central de esta
reunión. En una retrospectiva, buscamos generar una conversación
sana,donde predomine la autocrítica,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 esprint 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 pedirle su renuncia, sino 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 vídeosque toman demasiado tiempo en cargar. Una
vez identificado el problema, ya sea humano o técnico, el conjunto debe
planificar una posible solución,y asignársela a uno o varios miembros que se
encargarán de que ese problema no se repita. La retrospectiva no solo se
trata de buscar problemas,debemos destacar por igual lo bueno, no solo
para fomentar una cultura donde los méritos sean valorados en el equipo,
sino para identificar los puntos fuertes y aprovecharlos al máximo. 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 los empleados, más que con una sensación
de culpa, con una motivación para mejorar el equipo. La retrospectiva es un
momento para pensar nuevas ideas, y nuevas 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 y examinar los resultados.Las retrospectivas nos ayudan a
generar visibilidad sobre la dinámica del grupo e identificar las fortalezas y
debilidades del equipo, y, en especial, a crear un proceso permanente de
mejora y adaptación constante para construir un equipo más fuerte y más
eficiente en cada Sprint.

Qué es un Scrum master

Probablemente, la figura más conocida y la que más sencillamente podemos
relacionar con el concepto de Scrum es el Scrum Master. El Scrum Master es
uno de los roles de Scrum y frecuentemente lo encontramos en el medio del
proyecto, conectando todas sus partes para generar una unidad
funcional. Antes de analizar qué es un Scrum Master,comencemos
definiendo qué no lo es, porque, precisamente, por ese rol central y la
capacidad de colaborar con todos los participantes del proyecto es que
posiblemente este sea el rol que encontramos más mal aplicado con más
frecuencia. Arrancamos diciendo que un Scrum Masterno es lo mismo que
un project manager o un administrador de proyectos. Tampoco es un
cliente, ni es responsable de los resultados del proyecto. Y, definitivamente,
no es el jefe del equipo. Suena confuso, es cierto. Eso es porque estamos
acostumbrados a trabajar en un sistema jerárquico donde los proyectos los
dirige, usualmente, una persona que está en un rango de autoridad
superior y en muchos casos, el administrador de un proyectoes el mismo
jefe o el cliente.Este, afortunadamente, no es el caso de Scrum. Si tuviera que
reducir al máximo la definición del Scrum Master y solo pudiera usar una
palabra, lo definiría como "facilitador". Esa es la persona que se encarga de
que todo funcione correctamente para todos los demás. Se dice fácil, pero
no lo es para nada. El Scrum Master posee una serie de responsabilidades
asignadas,todas orientadas a que la producción del equipo sea fluida y
ocurra sin interrupciones. Su trabajo principal consiste en eliminar cualquier
obstáculo que se le presente al equipo y permitirles que se centren
únicamente en cumplir con los objetivos del sprint, sin que ninguna
distracción los retrase. Un buen Scrum Master no solo se encarga de ayudar
a su equipo,sino que también genera equipos autosuficientes, con la
capacidad de organizarse de manera proactiva. Por el contrario, un mal
Scrum Master suele aparecer donde se asignan project managers para este
rol, confundiendo las diferencias entre ambos. Estos últimos, si no están
familiarizados con Scrum, van a tener la tendencia de controlar a los equipos
y asignarle tareas a cada miembro según su criterio individual, perdiendo
por completo la iniciativa del grupo y su capacidad de autoadaptarse al
proyecto. El Scrum Master, además, es la persona del equipo encargada de
gestionar y mantener en funcionamiento todos los procesos y rituales de
Scrum y evitar que se incorporen malas prácticas o se ignoren los procesos
durante la etapa de desarrollo. En muchos casos, dependiendo de la
madurez y experiencia del grupo, el Scrum Master debe dedicar tiempo para
orientar y asesorar a los miembros del equipo que así lo necesiten. Esto hace
que sea difícil estandarizar el tiempo que toma gestionar un proyecto. En
caso de que el Scrum Master trabaje con diferentes equipos
paralelamente, debe tomarse en cuenta que cada equipo es diferente y va a
requerir más o menos tiempo en diferentes momentos del proyecto. Por
eso, debe tener la libertad de asignar el tiempo que considere pertinente, en
vez de atender un conteo estricto de horas por grupo. Para resumir este rol,
el Scrum Master no debe considerarse como un jefe, ni una figura de
autoridad.Sino como un facilitador para los miembros del equipo y un
gestor que se asegura de que los procesos de Scrum se completen
correctamente durante todo el proyecto.

Funciones y características de un Scrum master

El Scrum Master debe cumplir con una serie de tareas dentro del
proyecto. Pero este rol en particular, no solo se trata del qué, sino del
cómo. Para todas las tareas que desempeña un Scrum Master debe mostrar
una actitud abierta y empática,al mismo tiempo que tiene activado su
radar para detectar cambios en la moral del equipo o patrones que tiendan
a generar problemas en las entregas. El Scrum Master dedica la mayor parte
de la jornada a eliminar obstáculos para todos los miembros del
equipo. Usualmente, luego de que acaba el scrum diario, ya debe tener una
lista de problemas por resolver,posibles riesgos que prevenir y situaciones
que bloquean, de alguna forma, el trabajo del equipo. Por ejemplo,
imaginemos que estamos en un proyecto para escribir un libro de cocina y
durante ese 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 trabajoporque
aún no le entregaron las imágenes de la sesión fotográfica, el Scrum Master
se puede encargar de consultar con el fotógrafo y sugerirle al empleado que
elija otra tarea para que avance mientras se elimina este obstáculo. Como
ves, durante todas sus interacciones con el equipo, el Scrum Master
establece un ambiente, donde el equipo pueda ser eficaz. No se limita a
eliminar un obstáculo, sino que guía al equipo para que se mantenga igual
de productivoy no pierda de vista los objetivos del sprint en ningún
momento. Para mantener la productividad alta, el 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.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. Por ejemplo, podría incluir en el sprint tiempo
extra para leer la documentación y hacer pruebas de control de
calidad.Dependiendo de las características, el presupuesto y la organización
donde trabajanpodemos encontrar tres diferentes tipos de Scrum Master. El
Scrum Master rotatorio, cuando un miembro del equipo es asignado para
ejercer este rol durante un sprint, y al siguiente sprint, el rol se le asigna
rotativamente a otra persona. La idea de este estilo es que todos los
miembros del equipointerioricen al máximo los valores de Scrum y de paso,
tener Scrum Masters con conocimiento profundo sobre el equipo, porque
son parte de él. También tenemos el Scrum Master de tiempo parcial. En
este caso, un miembro del equipo asume el cargo de Scrum Master pero de
forma compartida con su cargo actual.Por otro lado, el Scrum Master de
tiempo completo es una persona cuya única responsabilidad es cumplir su
función como Scrum Master de un equipo. Esta modalidad se ve
frecuentemente en empresas pequeñas o en proyectos particularmente
complejos. Finalmente, tenemos el Scrum Master de tiempo completo
compartido.Se dedica específicamente a ser Scrum Master, pero desempeña
su rol en diferentes equipos. La modalidad de tiempo compartido es una de
las más comunes en empresas grandes con muchos proyectos.

Interacción del Scrum master con el equipo

El equipo de trabajo y el Scrum Master trabajan codo a codopara sacar
adelante al proyectoy mantienen una relación muy cercana durante toda la
etapa de desarrollo. Muchas veces, la relación con el equipo se describe
como la de un líder servidor porque, efectivamente, el Scrum Master tiene
una relación dual con el equipo. Por un lado, su quehacer diario es
ayudarlos, estar pendiente de todas sus necesidades y que se mantengan
productivos, pero por el otro, es la persona que motiva y organiza todas las
reuniones para que se alcancen los objetivos. Entre el Scrum Master y el
equipo no debe existir una relación de poder,pero sí una de liderazgo. Por
extraño que pueda sonar para muchos, el Scrum Master no tiene ninguna
autoridad sobre el equipo, así que está fuera de su alcance tomar decisiones
sobre lo que se hace, como asignarle una tarea particular a alguien, opinar
sobre el código de un desarrollador o despedir a uno de los miembros por
no obedecer. Al contrario, el nivel de comunicación con el equipo siempre
debe ser como iguales y en un entorno de confianza.Con una dirección sana
y generando espacios segurosdonde los empleados saben que no corren
ningún riesgo si acuden al Scrum Master cuando tienen un problema. Así
desaparece el factor miedo y se abre camino a una comunicación abierta. El
Scrum Master no tiene control sobre el equipo, pero es importante
mencionar que sí tiene autoridad sobre los procesos de Scrum y además,
vela para que todos los rituales se ejecuten. También, tiene la capacidad de
modificar algunos elementos según lo considere necesario, siempre con el
objetivo de mejorar la productividad del equipo o agregar valor al
proyecto. A la hora de hacer estimaciones o comprometerse con los
objetivos, es común que los equipos tengan la tendencia a asumir cargas
excesivas de trabajo o buscar metas poco realistas. Esto ocurre por muchas
razones, desde un exceso de optimismo, hasta la falta de consideración de
los detalles. Es aquí donde entra en acción otro de los superpoderes del
Scrum Master que es evitar que el equipo se sobrecargue de trabajo. Al
conocer el historial de sus entregas anteriores y las capacidades de cada
miembro,el Scrum Master debe guiarlos para que se compromentancon
objetivos más realistas. El Scrum Master es el protector del equipo que evita
que se asigne demasiado trabajo y que se fuerce al equipo a tomar metas
demasiado difíciles.Busca siempre equilibrar la carga de trabajo, evitando el
llamado burn out o agotamiento por trabajar excesivamente durante
demasiado tiempo. Pero todo esto debe hacerse manteniendo una
perspectiva equilibrada y siempre teniendo en cuenta la ejecución del
proyecto para evitar el punto opuesto, que es crear un equipo
autocomplaciente que solo se preocupa por su comodidad sin
comprometerse con el proyecto y asumiendo metas poco ambiciosas. El
Scrum Master es como el entrenador personal del equipo, es el que ayuda a
mantener una dieta equilibraday a ejecutar correctamente tus ejercicios. El
entrenador no puede obligarte a hacer un ejercicio que no quieres hacer.En
vez de eso te va a recordar cuáles son tus metas y los beneficios que quieres
alcanzar mediante todo este esfuerzo.Un buen entrenador, al igual que un
buen Scrum Mastersiempre te va a mostrar el camino y te va a dar la
motivación necesaria para trabajar al máximo y hacer que tú mismo alcances
las metas.

Interacción del Scrum master con el dueño de producto

El Scrum Master y el dueño del producto son en apariencia muy similares, y
hasta coinciden en varias tareas, sin embargo, sus prioridades y enfoques
son totalmente distintos. Por un lado, el Scrum Master se va a relacionar con
el proyecto y el backlog desde una perspectiva del grupo, y se encargará de
adaptar, motivar y eliminar cualquier impedimento que tenga el equipo para
conseguir los objetivos del backlog. Por otro lado, el dueño del producto
enfoca su rol desde la perspectiva del producto, tratando de agregarle
valor a través de las tareas que agregue en el backlog. El punto de
coincidencia más frecuente entre estos dos roles es la lista de tareas. 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, la lista de tareas o backlog es responsabilidad del dueño
del producto, que es el único que tiene permisos para agregar o eliminar
tareas. 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 dueño del
producto, es determinante para que la lista de producto tenga mayor
probabilidad de cumplirse. Detalles tales, como, los retos tecnológicos, los
recursos disponibles y las fortalezas o debilidades del equipo, tendrán la
visibilidad correcta. A la hora de trabajar en la edición de la lista de
tareas, mientras el dueño del producto debe tratar de agregar valor y
avanzar al máximo, el Scrum Master cumple su rol de protector del
equipo; evita que se le asignen más tareas de las que puede cumplir y
negocia y delimita el alcance de cada una. Es importante mencionar que el
objetivo de esta labor no es que el equipo trabaje poco ni escapar de todas
las tareas posibles; al contrario, un entorno desafiante, generalmente da
buenos resultados, pero, siempre manteniendo un equilibrio, para hacerlo
de una forma saludable; evitando el trabajo excesivo y la posible frustración
del equipo en caso de no lograr sus objetivos. Gracias a su conocimiento del
grupo, de los resultados de cada sprint y las observaciones de cada
retrospectiva, el Scrum Master puede darle un excelente feedback al dueño
del producto, ayudarle a calcular los objetivos y hacer que sean razonables,
según los recursos de los que dispone.

El Scrum master en el Scrum diario

El rol principal de Scrum Master durante el Scrum diario es organizar el
evento y 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, por ejemplo, que la reunión dure 15
minutosy mantener acotadas la participación de los empleados.Sin embargo,
un error típico es considerar que el Scrum Masteres el protagonista del
Scrum diario. Muchas veces, los miembros del equipo le hablan
directamente, como si fuera él la persona a la que deben informar el estado
del proyecto. Por el contrario, la función del Scrum Master es única y
exclusivamente de facilitador, es quien organiza la reunión, toma notas y
controla los tiempos. Pero ahí acaba su alcance. No olvidemos que este no
es un rol de jefe y que se encuentra al mismo nivel de los demás
miembros. El Scrum Master debe fomentar que los miembros del equipo se
dirijan en todo momento a sus colegas, manteniendo una comunicación
directa y fluida,porque el Scrum diario se trata de sincronizar con el
equipo, 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,asistan al Scrum
diario; si por alguna razón no puede asistir,la reunión puede celebrarse sin
ningún impedimento. De hecho, un buen Scrum Master debe incentivar este
tipo de conductas, donde el equipo se auto organice. Durante el Scrum
diario, el Scrum Master está llamado a hacer que se cumplan los
protocolos y buscar que la reunión se mantenga dentro del tiempo estimado
de 15 minutos. Sobra decir que este no es un número escrito 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 el día, y que se detecte
cualquier obstáculo que impida cumplir con los objetivos del 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, 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 para guiarlos y
mantener fluida la comunicación, para que sean ellos quienes decidan y
tomen la decisión acá. Lo mismo ocurre cuando detecta que el equipo tiene
problemas para finalizar una tarea o alcanzar las metas. En este caso, debe
generar la visibilidad del problema y apoyar al equipo para encontrar una
solución,que puede ir, desde dividir el problema en partes más
simples, hasta replantearlo y buscar otra forma de resolverlo,o buscar ayuda
externa.

El Scrum master durante la planificación del Sprint

Al igual que en el Scrum diario,el Scrum Master es quien se encarga de
organizar la reuniónpara 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
negociar las tareas que se van a trabajar en el próximo sprint.Aquí, el Scrum
Master debe mantener un punto de equilibrio entre los demás roles que
actúan en la reunión. Por un lado, debe trabajar con el dueño del
producto,ayudándole a establecer las tareas, delimitarlas y, de ser necesario,
adaptarlas a las condiciones y recursos actuales.Cada tarea debe ser clara y
de fácil comprensión para los miembros del equipo. El Scrum Master apoya
al dueño del producto para que pueda definir al máximo su visión del
producto y la pueda llevar a cabo con el equipo disponible.Por otro lado,
debe cumplir su rol de protector del equipo y evitar que los objetivos sean
demasiado ambiciosos, que se asigne más trabajo del que se estime
posible y evitar que el equipo de trabajo termine sobreesxplotado. Para
lograr ese punto de equilibrio, el Scrum Master negocia tanto con el dueño
del producto como con el equipo, siempre tomando conciencia de que debe
ser imparcial con ambas partes y su objetivo principal siempre es finalizar el
proyecto a tiempo, concretando al máximo la vision plasmada en la lista de
producto. Durante la planificación del sprint se revisa en detalle la lista de
producto o backlog y, en conjunto con el equipo, se define un objetivo
posible para el sprint, según el cual se escogen las tareas relacionadas y que
sean factibles durante este periodo.Todos los miembros del equipo analizan
cada una de las tareaspara estimar el nivel de esfuerzo y dificultad. Durante
este proceso, el Scrum Master debe asegurarse de que el equipo comprende
el objetivoque busca alcanzar el dueño de producto en cada una de las
actividades. Mientras el equipo estima el nivel de dificultad, el Scrum Master
activa sus poderes de guía y liderazgoporque, aunque si bien es cierto que
no tiene injerencia en la estimación que da el equipo, sí puede recordarles a
ciertos errores que se cometieron en el pasado en tareas similares y sugerir
que se revalúe una estimación. El objetivo es tener estimaciones
realistas para programar correctamente el tiempo y el esfuerzo que se va a
invertir en cada sprint.

El Scrum master durante la revisión del Sprint

A diferencia de otros rituales 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, y deja paso a los demás miembros del equipo. La revisión
del sprint es dirigida por el dueño del producto,quien se encarga de mostrar
cada tarea elegida en el sprint y su correspondiente efecto en el
producto. 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 del
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 la duración de este. 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. Pero fuera
de estos puntos, el Scrum Master debe mantenerse al margen y ceder el
control al dueño del producto. Es un error típico que el Scrum Mastertenga
instintivamente la tendencia a dominar la reunión.Pero es crucial que
durante la revisión del sprint, el dueño del producto mantenga el rol
principal, y muestre su visión proyectando el panorama del proyecto a todos
los asistentes.Así mismo, aunque el Scrum Master guía y mantiene
alineados a los participantes de la reunión, debe evitar presionar o ejercer
demasiado control que pueda afectar la exposición del dueño del
producto. Algunas tareas que sí puede completar el Scrum Master para esta
reunión, es facilitar información complementaria para los asistentes. Por
ejemplo, un listado de las tareas que se incluyeron durante el
sprint.Mencionar los principales logros o aciertos. Destacar el rol de algún
miembro del equipo de desarrollo que aportó de forma especial durante el
sprint. Y presentar indicadores clave, como el tiempo que tomó cada
tarea, el aumento o disminución de las tareas aceptadas, y, en caso de que
aplique, los errores o bugsque se corrigieron en el camino. De ser posible,
esta información adicional se puede enviar antes de la revisión del
sprint. Así, se garantiza que todos los asistentes se encuentren debidamente
informados y lleguen a la reunión con un contexto y una perspectiva
formados.

El Scrum master durante la retrospectiva

Durante la retrospectiva, el rol principal del Scrum Masterdebe ser, como en
todos los casos, el de facilitar, pero esta vez se trata de ayudar a que el
equipo de trabajo identifique ideas para mejorar. El Scrum Master debe
aportar su capacidad de análisis para encontrar detalles que el equipo pase
por alto y sus dones de liderazgo para mantener un espacio segurodonde
predominen las soluciones y el espíritu de grupo. No olvidemos que la
restrospectiva no es una rendición de cuentas, el Scrum Master debe alejarse
del rol de la autoridad. Aquí es particularmente importante mantener
siempre en claro esa relación de iguales que hay con el equipo para generar
confianza y seguridad. La retrospectiva es un proceso de autoanálisis donde
el Scrum Master trata de sacar a la superficie las situaciones que no han
funcionado biendurante el sprint, los problemas que necesitan solución y
cualquiera situación que requiera la atención del equipo.Esto lo hace en un
tono conciliador, constructivo y sin poner énfasis en buscar culpables. Sin
embargo, el Scrum Master debe ser asertivo en todo momento, y de ser
necesario, señalar concretamente el problema que necesita
solución. Durante la retrospectiva, el Scrum Master deja espacio al
equipopara que haga autoanálisis.Solo cuando encuentra problemas que el
grupo no ha mencionado, 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 cercapara detectar
su aparición.Cualquier situación, que alguna forma genere resultados
anómalos en repetidas ocasiones, debe ser analizadapara evitar que tome
por sorpresa al equipo. Por ejemplo, si cada vez que el equipo de
trabajo actualiza su sistema operativo, aparecen problemas de
compatibilidadpara desarrollar su software o si cada vez que recurren a un
proveedor en particular sufren retrasos o problemas de calidad. Conociendo
estos patrones que muchas veces pasan desapercibidos, pueden dedicarse
recursos y tomarse medidas para evitar que se repitan El ambiente de esta
reunión es constructivo en todo momento. Se debe poner menos atención a
las metas que no se cumplieron y dedicar todo el tiempo posible a encontrar
las causas que provocaron esa situación.Justamente por eso, el Scrum
Master mantiene una funciónde arbitraje y guía durante toda la
retrospectiva. Y si detecta que la conversación se dirige hacia culpar
personas, hacer hincapié en las situaciones y mantener la tensión del
grupoen solucionarlas en equipo. El Scrum Master aporta a la reunión un
ambiente de seguridad y confianza para que los miembros se sientan
cómodos al hablar de los problemas que tuvieron, que comprendan que se
encuentran en un espacio seguro, y que hablar de esto no significa que los
van a despedir o castigar,sino que están colaborando con la mejora y
adaptación constante del grupo. Durante la retrospectiva, no solo se buscan
las cosas que salieron mal, el Scrum Master también debe asegurarse que se
ponga atención a los aciertos tanto del equipo como individuales.Además
de fomentar un cultura de equipo donde los logros y problemas siempre se
suman en conjunto. Finalmente, es recomendable que el Scrum Master
gestione una bitácora de retrospectivas, donde se mencionen las cosas que
salieron bien, los problemas y las soluciones que sugieren los miembros del
equipo. Por cada problema y su respectiva solución, debe asignarse un
miembro de equipo que se haga responsable de aplicarla.Esta bitácora se
revisa durante las siguientes retrospectivaspara detectar tendencias,
patrones y darle seguimiento a la implementación de las soluciones que se
encontraron.Llevando una bitácora detallada y asegurándose de que los
miembros del equipo se hagan responsables de implementar las
soluciones, el Scrum Master garantiza que cada retrospectiva tenga un
impacto positivo real sobre el proyecto.

Que es un Product Owner

El dueño de producto es uno de los roles de Scrum que trabaja en conjunto
con el Scrum Master y el equipo de desarrollo, para crear un proyecto. Como
su nombre sugiere, es la persona que vela por el resultado del
proyecto,pero, en este caso, el término "dueño" no implica propiedad,sino
que se refiere a un contexto de compromiso y relación de control con el
producto. En otras palabras, no es necesariamente la persona que paga el
proyecto o el dueño de la empresa, sino quien define la forma final que
tendrá el producto. Para explicarlo en pocas palabras, el dueño de producto
es el responsable de maximizar el valor del producto. Esto lo logra
plasmando su visión en la lista de producto o backlog,donde incluye todas
las partes y funcionalidades que espera que tenga el producto; y
concretando esa visiónmediante el trabajo en conjunto con el equipo de
desarrollo. Para ver un ejemplo. Si el producto fuera un edificio,el dueño de
producto sería el arquitecto que define su forma,la función e interacción de
cada una de sus partes. Pero, al igual que un arquitecto, por más que
inspeccione la obra y se asegure de que sus planos se cumplen, no maneja
los detalles concretos del proceso de construcción, tales como el
ensamblado de un mueble o el concreto que se necesita en una pared. Su
rol se limita a indicar dónde deben colocarse,cómo deben verse, y cuál es su
funcionalidad. Para desempeñar este rol se necesita una persona que tenga
un profundo conocimiento del producto y todos los detalles relacionados
con él, como el usuario objetivo, el nicho de mercado al que apuntan, los
posibles competidores y todas las tendencias futuras que pueden afectar el
proyecto.Debe tener, también, un panorama claro del resultado final del
proyecto y dirigir el equipo hacia esa meta. El dueño de producto es un
único individuo. Debe evitarse que sea un comité o un grupo de personas. Si
bien es cierto que el dueño de producto puede atender los deseos y
necesidades de las partes interesadas, como clientes o juntas directivas, su
deber es procesar las peticiones y convertirse en un punto centralizado, que
incorpore todo lo que considere pertinente en el producto; pero siempre
manteniendo su criterio personal y una visión unificada. Precisamente, para
mantener esa versión unificada,la única persona que maneja el backlog o
lista de producto, es el dueño de producto, quien se encarga de agregar,
mantener y priorizar todas las tareas o historias que se encuentran
allí.Retomando el ejemplo anterior.Si el dueño de producto es el arquitecto
del proyecto, la lista de producto es el plano de su edificio.

Funciones y características de un dueño de producto

El dueño del producto debe tener un conocimiento profundo para delinear
la ruta por la que desea dirigir el proyecto, y canalizar todas las voces y
necesidades relevantespara incorporarlas en este proceso. Para ejercer este
rol, se necesita un individuo con ciertas habilidades, como apertura, instinto
de negocios y, en particular, habilidades de comunicación. El dueño de
producto, necesita mantener una política de apertura y disponibilidad con su
equipo, para que puedan contar con éla 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 dueño del
producto se ajusta y adapta para que cada sprint tenga el máximo impacto
posible. Las habilidades de comunicación son un factor crucial para el dueño
del producto, 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 otros departamentos de la
empresa. Todos ellos aportando ideas y solicitando que sus intereses estén
representados en el producto.El dueño de producto aplica su criterio para
escuchar todas esas voces pero se mantiene fiel a su visión. Únicamente
toma lo que considere que aporta valor al proyecto y descarta todo lo
demás. Un buen dueño de producto muestra compromiso con el
proyecto haciendo lo que sea necesario por tener el mejor producto
posible. Eso implica mantener una estrecha relación con el equipo, pero
puede investigar y profundizar sobre las últimas tendencias y el alcance de
su producto.Además, debe mantener su propio ego a raya y dedicar
tiempo para escuchar a los demás, probar nuevos caminosy aceptar con
humildad las críticas. Para que el dueño de producto pueda desenvolverse
con libertad en su trabajo, toda la organización debe respetar sus decisiones
con respecto al producto, estas decisiones se reflejan en el contenido y en la
priorización de la lista del producto. Debido a que el dueño de producto es
el único que controla la lista de producto, o backlog, es también el
responsable de crear tareas o historias de buena calidad. Y a la hora de crear
tareas, debe asegurarsede expresarse claramente en cada una de
ellas, utilizar un lenguaje fácil de entender, detallar correctamente los
objetivos que desea cumplir, las partes del producto que serán afectadas, las
posibles dependencias y el criterio de aceptación para saber cuándo está
terminada la tarea.Siempre que pueda, el dueño de producto debe dedicar
tiempo a priorizar y ordenar los items que se encuentran en la lista del
producto, ordenarlos de forma que sea posible entender su orden y
optimizar ese orden para coincidir al máximo con los objetivos del sprint.

Interacción del dueño de producto con el equipo

El dueño del producto dentro de un proyecto Scrum debe siempre guiar a su
equipo y trabajar estrechamente con élpara poder concretar juntos todos los
conceptos que planificó. Si el proyecto fuera una escultura, el dueño del
producto sería la mente y los ojos del artista, pero el equipo de desarrollo es
la mano y el cincel con el que talla el mármol siguiendo su guía.Ambos roles
se necesitan mutuamente para terminar la obra. El dueño del producto debe
tener clara su visión del proyecto y estar comprometido con él para poder
alentar, motivar y transmitir asertivamente esas ideas al equipo, y asegurarse
así de que obtendrá una copia fiel de sus ideas plasmadas en la idea del
producto. La única persona que controla la lista de producto o backlog es el
dueño del producto. Únicamente él decide qué tareas entran o salen y el
orden de prioridad que tienen.Como esta lista es la que determina las
acciones que deben tomar los miembros del equipo, el dueño del producto,
al final, determina el rumbo del equipo. Sin embargo, y esto es importante
de recordar, el equipo de desarrollo, a su vez, tiene total control sobre las
tareas que elige implementar en cada sprint. Nadie puede obligarlos a tomar
más o menos de las que consideren factibles. Gracias a este equilibrio de
fuerzas, al dueño del producto le toca negociar y acordar con el equipo
cuáles serán las tareas y los objetivosque desea cumplir en cada
sprint, tratando siempre de agregar el máximo de valor en cada etapa, al
mismo tiempo de mantener motivados a todos los participantes,mientras se
crea un entorno que se mantenga estimulante,con los objetivos cada vez
más ambiciosos. El dueño del producto se asegura de que las tareas están
explicadas en un lenguaje claro y específico,pero además, especifica los
parámetros a partir de los que se considerará terminada una tarea, sus
alcances y las dependencias y comprueba que todos los miembros
involucrados en esta tarea la entienden. A veces, para proyectos más
complejos, el dueño del producto puede trabajar con diferentes equipos,
cada uno de los cuales trabajará una parte de su producto. En estos casos, es
fundamental que el dueño del producto mantenga abiertos los canales de
comunicación y que utilice todas sus habilidades de comunicación para
mantener sincronizados los equipos con que trabaja y evitar que se
fragmente su idea con diferentes estilos, implementaciones y soluciones a
problemas. Aquí, el dueño del producto no solo cumple un rol de guía, sino
también de unificador. La principal actitud del dueño de producto frente al
equipo de desarrollo es de respeto. Debe evitar controlar directamente la
forma en que se abordan e implementan sus ideas y debe dejar que el
equipo encuentre por sí mismolas mejores soluciones a los problemas. No
perder nunca de vista que ellos son los especialistas en la implementación y
su rol es únicamente el de guiarlos hacia ese producto ideal.

Interacción del dueño de producto con el Scrum master

El punto común de trabajo más frecuente entre el dueño de producto y el
Scrum Master, siempre será la lista de producto. Aquí es donde ambos roles,
cada uno desde diferentes enfoques se unen para pulir, mejorar y enriquecer
todas las ideas que componen el producto y el quehacer del equipo de
trabajo. El Scrum Master abordará la lista desde el punto de vista del
equipo y la implementación de protocolos, mientras que el dueño del
producto la abordará siempre con vistas a generar el máximo valor posible,
mientras integra las voces y necesidades de las partes interesadas o
stakeholders. Esta diferencia de planteamiento no debe significar nunca una
rivalidad,sino, por el contrario, un complemento. Los dos roles juntos, no
solo pueden enriquecer a un producto a nivel de sus tareas, sino, motivar y
dirigir al equipo para que mantengan al máximo su rendimiento y
compromiso con el proyecto. El dueño del producto se asegura de que las
tareas que incluye son claras, delimitadas y comprensibles para el
equipo. Para esto, es crucial la función del Scrum Master. Su conocimiento
profundo del equipo, sus ritmos, habilidades y personalidades, puede ser de
gran ayuda a la hora de incorporar nuevas funcionalidades y aprovechar al
tope los recursos disponibles.Mientras el dueño del producto se preocupa
por establecer y comunicar su visión estratégica detrás del producto, el
Scrum Master se encarga de transmitir al equipo esa visión; motivarlo y
comprometerlo para convertir la visión en una realidad. Una buena
combinación de estos dos roles puede tener un efecto significativo en el
ambiente del proyecto. Por ejemplo, puede mantener la moral y la
productividad del equipo en los más altos niveles, simplemente,
manteniendo abiertas las líneas de comunicación y atendiendo las razones
del equipo, para definir prioridades, basadas en lo que es razonable con los
recursos disponibles; en vez de fijar objetivos arbitrarios, orientados a las
metas de negocios. Ambos pueden colaborar, también, para mejorar el flujo
de la comunicación dentro del proyecto. Al trabajar codo a codo con el
Scrum Master y transmitiendo su estrategia, el dueño de producto
garantizaque la información llegará clara para el equipo, y, gracias a que la
comunicación fluye en dos vías, el Scrum Master puede encargarse de
transmitir las preocupaciones o los mensajes del equipo.

El dueño de producto en el Scrum diario

Al igual que todos los miembros del equipo el dueño del producto está
invitado a asistir al Scrum diario para conocer el avance del proyectoy
sincronizar esfuerzos con todos los participantes. Sin embargo, para este rol,
aunque la asistencia es útil y recomendable, no es necesariamente
indispensable.Esto es así, porque el aporte principal del dueño de
producto es la lista de proyectoy para el momento en que se desarrolla el
Scrum diario,todas las tareas relacionadas con el sprint ya debieron ser
discutidas y aclaradas por el equipo y el Scrum Master durante la reunión de
planificación del sprint. Pero, sin importar que no se encuentre en la
obligación de asistir diariamente, sí es fundamental que se presente con
frecuencia, al menos dos o tres veces por semana como mínimo, para estar
al tanto del pulso del proyecto, conocer cuáles son los posibles riesgos y
aclarar cualquier duda del equipo que pueda surgir durante el desarrollo de
una tarea. Porque no importa lo bien redactada que esté una tarea, lo bien
delimitado que esté su alcance o el tiempo que se dedicó para analizarla con
el equipo, es común que una vez que se inicia el trabajo en una actividad, el
equipo comience a descubrir nuevas aristas, interpretaciones o posibles
conflictos en la implementaciónque no se contemplaron durante el proceso
de planificación, ya sea por falta de atención a los detalles o porque,
sencillamente, era imposible saberlos hasta aplicarlos en un entorno
real.Durante el Scrum diario, la presencia del dueño del producto debe ser
específicamente para aclarar dudas o enriquecer la implementación de una
tarea, siempre manteniendo una distancia con el equipo para respetar su
espacio y su rango de acción. El dueño de producto debe recordar en todo
momento que los especialistas y expertos son los miembros del equipo, sin
importar cuál sea su conocimiento del producto, grado académico o
jerarquía en la empresa; siempre debe dejarles total libertad para
implementar lo que ellos deciden, porque son los únicos que conocen los
detalles específicos de la implementación. De igual forma, debe impedir
obstaculizar el trabajo del Scrum Master. Por ejemplo, haciendo que el
Scrum diario se extienda más de los quince minutos estipulados, asignando
tareas específicas a los miembros del equipo y en general, tratando de dirigir
el trabajo del equipo hacia un rumbo específico, rompiendo la
independencia y autoorganización del equipo de trabajo. Por supuesto,
sabemos que el dueño del producto por lo general tiene un nivel de
compromiso alto con el proyecto y un conocimiento profundo sobre todas
sus partes, y es normal que sienta deseos de controlar el resultado de las
tareas que creóo guiar la implementación de una funcionalidad que pasó
horas analizando. Sin embargo, en la filosofía de Scrum, todo se trata del
trabajo en equipo y respetar la función de cada participante. Aunque en
algunas ocasiones, el dueño del producto no esté de acuerdocon alguna
implementación, debe delegar y permitir al equipo aplicar sus conocimientos
expertos para resolver el problema.

El dueño de producto durante la planificación del Sprint

La planificación del sprint es una reunión crucial para todo el proyecto. Y en
ella se requiere la presencia del dueño de producto y su liderazgo. Al ser la
única persona que controla las tareas que entran o salen de la lista del
producto, el dueño del producto es una pieza indispensable durante la
planificación del sprint. Antes de asistir a esta reunión, necesita
confeccionar un trabajo de preparación para la lista del producto. Para esto,
debe leer y familiarizarse con las tareas que espera completaren el futuro
cercano. Asignar un orden a todas las tareas de acuerdo a su prioridad o
dependencia y, en caso de ser necesario, incluir nuevas tareas,basándose en
los resultados y descubrimientos del sprint anterior o las solicitudes de las
partes interesadas o stakeholders. Parte de ese trabajo previo, incluye un
proceso que, aunque consume tiempo, es crucial asegurarsede que todas las
tareas están redactadas correctamente. Esto significa, comprobar que
incluyen información clara y detallada, que toman en cuenta posibles
dependencias, y en particular, que tienen claramente definidos los objetivos
y criterios de aceptación. Estos serán la guía que se utilizará para ejecutarlas
pruebas de control de calidad y también para que los miembros encargados
de implementar la tarea tengan claros cuáles son los parámetros para
considerar esta tarea como terminada.Una vez iniciada la reunión de
planificación, el dueño del producto debe practicar sus dotes de
dirección,compartiendo con el equipo su estrategia, detallando la
importancia de las metas trazadas para agregar valor al producto y
procurando transmitirles su visión. Juntos, todos los miembros del proyecto
van a explorar las tareas que preparó y priorizó el dueño del producto, y
leerán detalladamente y debatirán todas las posibles implicacioneso
requerimientos para desarrollar cada tarea. Una vez analizadas las tareas, se
procede a definir la meta del sprint. Aquí, una vez más, el dueño del
producto debe negociar con el equipo para que represente lo mejor posible
su estrategia. La meta de sprint, de preferencia, debería concentrarse en una
funcionalidad, experiencia del usuario o interacción; pero en caso de que las
tareas sean muy distintas entre sí, puede continuar sin definir una meta
específica. Cuando se determina la meta, el grupo pasa a seleccionar las
tareascon las que considera que puede comprometerse durante el sprint y
aquí, aunque el dueño del producto puede sugerir y negociar, la última
palabra sobre las tareas que se van trabajar en el sprint la tiene,
exclusivamente, el equipo de trabajo. La función del dueño del producto
consiste en velar por los intereses del producto, y aunque no puede obligar
a nadie, siempre que pueda, debe presionar para que el equipo elija la
mayor cantidad de tareas posibles, en particular, las que consideremás
importantes, ya sea para cumplir las metas del negocio,mejorar la
experiencia de los usuarios del producto o aumentar su valor. Debe hacer
todo lo posible por mantener un ambiente estimulante,avanzar al máximo
posible dentro de la capacidad del equipo y presionar para llegar a la
conclusión del proyecto o las metas solicitadas por las partes interesadas. Si
el proyecto fuera un auto y el equipo de trabajo su motor, el dueño del
producto es el piloto de Fórmula Uno que trata de empujar los límites y
llevarlo al máximo de rendimiento.Precisamente por eso, quien ejerce ese
rol, debe poseer la madurez y experiencia necesarias para saber cuándo hay
que presionar y cuándo es conveniente bajar las revoluciones. Se tiene que
desarrollar una empatía por el equipo y no perder nunca de vista que son
personas. A la hora de negociar las tareas siempre se debe respetar el
criterio y consejo del Scrum Master, quien velará por llegara un punto
intermedio donde se alcance el mayor rendimiento sin sobreexplotarel
valioso recurso humano.

El dueño de producto durante la revisión del Sprint

De todas las reuniones que se hacen a lo largo del sprint,posiblemente, en la
que más destaca el papel de dueño de producto es en la revisión del
sprint. Durante la revisión del sprint todos los participantes del proyecto se
reunen para examinar y probar todos los avances y logros de la última
iteración. El dueño de producto es quien guía esta reunión, y se encarga de
revisar, una por una, todas las tareas a las que el equipo se comprometió
durante la planificación del sprint. Va a exponer su descripción y los
requerimientos de cada tarea;para luego, llamar a un miembro del
equipo,usualmente, la persona responsable de la ejecución; y solicitarle que
haga una demostración práctica. Por ejemplo, si estamos trabajandoen una
aplicación móvil de entrega de comida, y una de las tareas de este sprint, era
incluirla funcionalidad de capturar los números de tarjeta de créditodel
usuario, sin necesidad de usar el teclado. El dueño de producto menciona
esta tarea,enumera los requerimientos; que, por ejemplo, no necesitenincluir
interacción con teclado, que sean sencillos de utilizarpor cualquier usuario
de dispositivo móvil y que sean seguros. Seguidamente, invita a un miembro
del equipo a hacer la demostración. La demostración, de un caso como
este, puede ser abrir la aplicación, buscar la seccióndonde se encuentran las
opciones 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 carácteres, y, finalmente, almacenar el número
digitalizado en la aplicación.Demostrando así, que el usuario puede ejecutar
pagoscon su tarjeta de crédito, sin necesidad de utilizar teclado.Una vez
terminada la demostración de cada una de las nuevas tareas, el dueño del
producto puede dedicar tiempopara mencionar cualquier tareaque por
distintos motivos no se pudo completar. También es posible explicar las
correcciones que se aplicaronbuscando mejorar el producto.Por último, el
dueño del producto hace un breve resumen de las nuevas
funcionalidades, analiza las posibles implicaciones de estos avances y traza
las líneas para lo que será el desarrollo futuro del proyecto. En muchos
casos, gracias a los cambios implementados en el sprint actual, se logran
desbloquear algunas tareas que antes no eran posibles o se descubren
nuevas funcionalidades potenciales gracias a los nuevos casos de uso y a las
nuevas condiciones en que se encuentra el producto. El demo del sprint es
una excelente ocasión, no solo para celebrar los triunfos del equipo, y
sincronizar con todos los participantes en el avance real del proyecto, sino
también, para permitir al dueño de producto exponer su estrategia y
proyectar una visión del producto a futuro.

El dueño de producto durante la retrospectiva

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. El dueño del producto está invitado a participar en esta
reunión como cualquier otro miembro del equipo. Sin embargo, su
asistencia no es obligatoria,principalmente porque el trabajo de todo el
sprint fue ejecutado por el equipo de desarrollo y su intervención en ello es
mínima. Es muy frecuente que el dueño del producto no asista a la
retrospectiva, que solo estén representados el Scrum Mastery los miembros
del equipo de desarrollo, ya que son ellos quienes están detrás del
avanceque se consiguió durante el sprint, y quienes más se benefician de
este espacio de auto análisis y adaptación. Sin embargo, algunos dueños de
producto aprovechan esta ocasión para seguir enriqueciendo su visión del
producto y conocer más a fondo a su equipo. Incluso, cuando se trata de
mostrar sus lados más vulnerables. Gracias a la dinámica de la
retrospectiva, el dueño del producto puede recopilar mucha información
valiosa que en el futuro le permitirá crear tareas de mejor calidad,tomando
en cuenta las capacidades del equipo y su perspectiva. Cuando en la
retrospectiva se habla de los aspectos que funcionaron correctamente y de
los logros que se alcanzaron durante el sprint, el dueño del producto 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 repetir
ese patrón. Por otro lado, a la hora de analizar los factores que salieron
mal,puede tomar nota de tareas que tal vez eran demasiado ambiciosas, que
tenían dificultades para implementarse, y por qué no, que estaban mal
diseñadas o redactadas. Pero tal vez, el momento más interesante para el
dueño del producto es cuando el equipo busca soluciones y
sugerencias para evitar que estos problemas se repitan. 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. Otra oportunidad
que puede aprovechar el dueño del producto es abrirse a la misma dinámica
del equipo y someterse a ese proceso de auto análisis y crítica constructiva,
escuchar los comentarios y sugerencias que llegan desde el equipo, y las
posibles mejoras que podría incorporar al desarrollar las siguientes etapas
del producto.Este ejercicio de humildad le puede aportar grandes
beneficios al dueño del producto, tales como, ampliar su rango de visión y
perspectiva del producto; enriquecer sus ideas con el conocimiento de los
expertos del equipo y conocer cuáles son los puntos más débiles del
producto.

Qué es un equipo Scrum

El equipo de desarrollo es 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á conformado 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 personaspresentan
problemas de comunicación y dificultades para manejar un flujo demasiado
alto de información.En proyectos más complejos que exijan más personas, se
debe 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, 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 muy
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 cambian 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, un diseñador puede ejercer la función de
control de calidaden caso de ser necesario. Lo más importante para un
equipo de Scrum es alcanzar los objetivos, adaptarse y mejorar
constantemente. Las reglas pasan a un segundo plano, por debajo de los
valores más importantes como la creatividad, el trabajo en equipo y las
entregas de productos de calidad a tiempo.Debido a su forma de trabajo y al
pensamiento de equipo, los equipos de Scrum tienden a desarrollar una
profunda camaradería, y el sentimiento de que se gana o se pierde
pertenece a todo el equipo,porque todos somos parte del mismo bando.

Funciones y características de un equipo Scrum

El equipo de desarrollo debe estar comprometido 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 se compromete a cumplir con
ciertos objetivos, que se convertirán en su misión principal durante todo el
sprint.El equipo trabajará día a día para hacer que estos objetivosse
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 del equipo de
desarrollo.Independientemente de quién sea el Scrum Master o el dueño del
producto, nadie tiene autoridad para decirle al equipo cuándo o
cómodesempeñar una tarea. Ellos tienen total libertad para elegir su
trabajo y la forma de resolver los problemas. Esta autodeterminación y
libertad no son gratis. Requieren que el equipo deba, también, autoregularse
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,disponibilidad, experiencia e intereses. Aunque cada uno de los
integrantes del equipo tiene su propia especialidad y ejecuta un rango de
tareas dentro del equipo, 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, en equipos de desarrollo
de software se evita subdividir el equipo en desarrolladores 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
miembros del equipo 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 forma de trabajo.Todos deben estar preparados
para intercambiar funciones y ayudar a cualquier compañero que se quede
rezagado. Esto no solo crea equipos más unidos, sino que también ayuda a
evitar rutinas tediosas y muchas veces, al experimentar nuevas formas de
trabajo se descubren detalles muy valiosos. Para finalizar, un punto que no
debemos olvidares que sin importar sus grados académicos o el tiempo que
llevan trabajando en la empresa, los miembros del equipo tienen
exactamente el mismo nivel jerárquico e importancia en el proyecto. Un
equipo Scrum está compuesto únicamente por pares en el que no hay
ningún coordinador o jefe, aplicándose al pie de la letra el viejo concepto de
que muchas cabezas piensan mejor que una.

Interacción del equipo Scrum con el dueño de producto

El dueño del producto es quien provee todas las tareas en las que trabajará
el equipo. Para ellos, este es el rol que traza la ruta que llevará el proyecto, y
deben poner especial atenciónporque comprendiendo su visión pueden
comprender mejor el producto en el que están trabajando. El punto de
encuentro donde se combina el trabajo del equipo de Scrum y el del dueño
del producto en la lista de proyecto. Aquí es donde, por un lado, el equipo
se alimenta de tareas por realizar, y, por el otro, el dueño del producto crea
nuevas tareaso 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, el equipo debe atender y respetar el liderazgo que ejerce el
dueño del producto sobre el proyecto. Sin embargo, aunque el dueño del
producto puede definir y priorizar todas las tareas, incluso sugerir cuáles
pueden ser los objetivos óptimos para el sprint actual, es el equipo quien
tiene la última palabra sobre el trabajo que va a completar y las metas con
las que se compromete. También, tiene la última palabra a la hora de
implementar las soluciones,y, aunque el dueño del producto tenga un
conocimiento avanzado sobre las características solicitadas en cada tarea, es
el grupo el único que puede decidir cómo se va a abordar este
problema. Eso sí, ese control siempre debe ir acompañado de una actitud
abierta para escuchar sugerencias y experiencias que pueda aportar el
dueño del producto. Cuando el equipo trabaja en la planificación del
sprint, debe escuchar con atención al dueño del producto, tratar de cumplir
con sus expectativas y entrar en sintonía con su estrategia. Pero no todo se
trata de escuchar,también se debe mostrar una actitud proactiva y
comunicar cualquier duda, opinión o crítica constructiva en el momento de
conocer una tarea. Durante el desarrollo del sprint, es muy posible que
cuando el equipo implemente las nuevas funcionalidades
solicitadas, encuentre problemas, incompatibilidades,o diferencias en el
funcionamiento esperado. Por ejemplo, se está desarrollando una página
web en la que se incluye la opción de compartir archivos, y cuando llega el
momento de implementarlo el equipo descubre que esta opción, --por la
forma en que está configurada--, puede abrir una brecha de seguridad para
toda la aplicación. En un caso como este, el equipo debe comunicar
inmediatamente sus descubrimientos al dueño del producto y en conjunto
adaptar la tarea y solucionar este nuevo problema.

Interacción del equipo Scrum con el Scrum master

Durante todo el proyecto, el equipo de trabajo colabora codo a codo con el
Scrum Master, ambos roles están estrechamente relacionados y dependen
mutuamente para poder trabajar. Es muy común y hasta deseable que se
desarrolle una relación de camaradería y confianza entre ambos, hasta que
el Scrum Master se vea como un miembro más del equipo de trabajo. El
Scrum Master es el protector del equipo y siempre debe facilitar el trabajo
de sus integrantes, escucharlos, guiarlos y mantenerlos motivados. En
respuesta a esta actitud, el equipo debe desarrollar su confianza en el
criterio y liderazgo del Scrum Master, así, ambos roles se potencian
mutuamente. En cualquier momento, cuando el equipo encuentre algún
problema para cumplir los objetivos del sprint debe acudir de inmediato al
Scrum Master para avisarlo de esta nueva situación. El Scrum Master no
necesariamente tiene todas las respuestas, pero parte de su rol es conocer
todos los detalles,tanto del equipo como del proyecto. Muchas veces, ese
punto de vista único puede ayudarnos a detectar algo que habíamos pasado
por alto, o detectar 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 ayudar a subdividir la tarea en
partes más simples o buscar la ayuda de otro experto. Cuando existen
diferencias de criterio entre los miembros del equipo,también se debe acudir
al Scrum Master para que funcione como árbitro imparcial y crea un entorno
apropiado para que ambas partes puedan dialogar y aportar ideas en
función de su conocimiento del proyecto y el equipo. Aunque el Scrum
Master protege y ayuda a organizar el equipo, no se debe confundir con un
administrador de proyecto, su rol es únicamente de guía, apoyo, y, en
particular, facilitador para que todos puedan trabajar sin obstáculos. Es el
equipo quien, de manera proactiva, debe organizarse y, en general,
autogestionarse sin intervención externa. Esta diferencia no significa que
deba existir una rivalidad o que deba verse al Scrum Master como una fuerza
externa o un disruptor en el equipo; al contrario, la comunicación debe ser
aún más fluida y transparente porque estamos entre pares.

El equipo Scrum durante el Scrum diario

Durante el Scrum diario tenemos la oportunidad de sincronizarnos o
detectar oportunidades y obstáculos, así que los miembros del equipo
deben asistir y participar en esta reunión siempre y ausentarse solo por
razones extraordinarias. En esta reunión los miembros del equipo son los
que generan el material de conversación. Cada uno debe tomar la palabra y
actualizar a todos los participantes sobre su avance, cubriendo al menos
estos tres aspectos: ¿Cuál fue el avance conseguido el día de ayer? Donde se
hace un resumen muy breve sobre las tareas realizadas desde la última
reunión. ¿Qué se planea conseguir el día de hoy? Y esto puede incluir
concluir tareas que quedaron pendientes el día anterior o elegir tareas
nuevas.En el caso de que no queden tareas pendientes, hay que buscar y
trabajar proactivamente en una acción que mejore el rendimiento del
equipo, como automatizar procesos, investigar un tema difícil del proyecto o
ayudar a alguno de sus compañeros.Finalmente, el miembro del equipo
debe mencionar qué obstáculos se encuentra a la hora de cumplir su
trabajo y enumerar cualquier problema que no le permita acabar sus
tareas. Esto puede abarcar un rango muy amplio de casosdesde problemas
técnicoshasta problemas con los requerimientos de la tarea elegida. Esta es
una reunión de sincronización más que una actualización del avance, lo que
significa que todos los miembros del equipo no solo deben mencionar su
estatus actual, sino también poner atención y escuchar el progreso de los
demás miembros del equipo, ya que, en muchos casos, puede ayudar a
comprender mejor un tema y a resolver dependencias que afectan las tareas
de otros empleados. Al momento de actualizar su estatus diario se debe
recordar siempre dirigirse en particular a los demás colegas del equipo en
vez de hacerlo hacia el Scrum Master o al dueño del proyecto. Aunque estos
dos roles son importantesy por supuesto, queremos incluirlos como
miembros del proyecto, los compañeros del equipo son los que más
necesitan conocer nuestro avance y descubrimientos más recientes. Esta
acción es muy importante cuando se trabaja en equipo y las experiencias de
cada individuo pueden aportar mucho en el desempeño general. Durante
esta reunión 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 miembros del
equipo, gracias a su conocimiento técnico, pueden detectar potenciales
errores que aún no afectan el productopero que pueden hacerlo en el futuro
inminente. Estos potenciales problemas también deben ser mencionados al
Scrum Master a manera de observación o comentario, para que tome nota y
se preparepara tomar las medidas necesarias de precaución. Los miembros
del equipo deben mantener su intervención acotada durante el Scrum diario
y durante toda la reunión, limitar su conversación a factores relacionados
con el proyecto. Deben evitar comentarios personales o divagar sobre temas
que no estén directamente relacionados en la resolución de una tarea y, a
ser posible, llegar previamente preparadoscon una lectura rápida de las
tareas que se van a discutir e ideas para implementarlas. Así se reduce el
tiempo de participación a lo estrictamente necesario y se permite a los
demás colegas presentar sin prisas, siempre ajustados a los 15 minutos que
debe tomar esta reunión.

El equipo Scrum durante la planificación del Sprint

Antes de llegar a la reunión de planificación del sprint, es buena idea que los
miembros del equipo dediquen un tiempo individual para leer todas y cada
una de las tareas que se van a debatir. Así pueden identificar errores,
problemas y consultas previamente y agilizarel flujo de la reunión. En ella se
acordarán las tareas que se completarán durante el siguiente sprint. El
equipo debe mantener una actitud proactivaa la hora de comentar, sugerir y
hacer todas las consultasnecesarias 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
resultadoscon una simple medida: el equipo completo debe
dedicaraproximadamente 30 minutos a 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 dueño del producto manifieste
sus sugerencias para las tareas que quisiera elegir, es únicamente el equipo
el que decide de forma unilateral las actividades con las que se va a
comprometer durante esta iteración. Este acuerdo lo deben hacer basándose
en el nivel de dificultad que presenta cada tarea. El equipo debe
responsabilizarse de la mayor cantidad de tareas posible 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 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 ayude a los empleados a tomar la decisión más
apropiada. En algunos casos es posible encontrar tareas que son
particularmente complejas. Una recomendación que me ha dado buenos
resultados es que si la tarea toma más de un día se debe desglosar en tareas
más sencillas que no tarden más de un día en completarse.

El equipo Scrum durante la revisión del Sprint

La revisión del sprint es una actividad donde se examina el avance del
equipo y el efecto de su esfuerzo aplicado en el producto. Es un momento
para sentirse orgullosos y motivarsecon todo el progreso conseguido. Todos
los miembros del equipo deben asistir a esta reunión. Y al menos los que se
ocuparon del trabajo que va a ser parte de la demostración deben estar
presentes y preparados para participar y hacer una demostración de su
aporte delante del resto de los miembros del proyecto.Durante todo el
proyecto,quien dirige la reunión y los temas que se van a debatir es el dueño
del producto. El equipo, por su parte, debe mostrar una actitud
atenta,escuchando todo el material que se presente y listo para
aclarar cualquier duda o demostración sobre las tareas.Se recomienda que al
menos un día antes el equipo haga una preparación previa para la
demostración y así garantizarque todo funciona en las condiciones
esperadas; que quienes se encargan de la prueba tienen todo lo que
necesitan y al planificar cómo comunicar el avance mostrando en
detalle todas sus capacidades e impacto sobre el producto. También,
minutos antes de que empiece la reunión, se recomienda tener todo
preparado para que se pueda utilizar y que sea funcional y si es
posible hacer una prueba rápida antes para que ningún problema distraigaa
los asistentes y poder abordar directamente el tema. Una vez empezada la
reunión, los miembros del equipo esperan a ser llamados y cuando llegue el
momento hacen una demostración que trate de generar la mayor cantidad
de información para los presentes.Por ejemplo, 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. Entonces, los
encargados de la demostracióndeben ser, de preferencia, quienes lo
desarrollaron. Así, no solo pueden mostrar la aplicación de esta parte nueva
del proyecto sino que también puede mencionar los pequeños detalles que
no se notan a primera vista o la gama completa de funcionalidades
implementadas. Después de la demostración todos los miembros del equipo
conocen a fondo las nuevas funcionalidades y capacidades del
producto. Esto, en muchos casos, cambia o amplia 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 miembros del equipo escuchando atentamente al dueño del
producto trazando las líneas y tendencias que debe seguir el producto a
partir de su actualización más reciente.

El equipo Scrum durante la retrospectiva

La retrospectiva es un momento de reflexión y autoanálisis que tiene lugar al
final de cada sprint y que puede ser especialmente útilpara los miembros del
equipo de desarrollo. 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 debe
compartir con sus colegastodas las cosas que considera que funcionaron
correctamentey los aciertos que tuvo el equipo. También debe hablar sobre
lo que considera que no funcionó tan bien, y no limitarse únicamente a
hacer autorreferencia sobre los problemas de su trabajo, sino que también
tiene la opción de comentar los problemas que encontró 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 eliminar. La principal acción que se debe ejecutar en esta fase es
encontrar la raíz central de un problema, identificar las causasy asignar un
responsable que trate de solucionarlo. Los miembros del equipo deben
aplicar un ejercicio de confianza con su grupo y hablar abiertamente de sus
propios errores, siempre comprendiendo que esto 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 al escuchar
comentarios y críticas constructivas, sino también hacer modificaciones y
aplicar nuevas técnicas o experimentar nuevas formas de trabajo para
cumplir con todos los objetivos del siguiente sprint.
Herramientas para gestionar proyectos Scrum
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, sin importar su
grado de complejidad, se pueden trabajar perfectamente con solo un equipo
comprometidoy 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 la lista de proyecto. Como su nombre
lo indica, es una lista donde vamos a incluir todas las tareas del proyecto. Y
es fundamental que tenga algún tipo de respaldo para que no olvidemos sus
contenidos.Tradicionalmente, y de nuevo, para conservar esa simplicidad,la
lista del producto 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 dueño del producto anota la nueva tarea en una
tarjeta y la coloca en un lugar físico que se convertirá en la lista del
proyecto. Durante la planificación del sprint el equipo elije las tareas, en este
caso, representadas en tarjetas autoadhesivas, y las mueve a una sección que
se convertirá en la lista del sprint, y determina el trabajo que se va a
completar durante la iteración actual. Finalmente, al terminar cada tarea, el
equipo va moviendo o marcando las tareas acabadas. Estas tarjetas se
utilizarán como una especie de guión durante la revisión del sprint. El dueño
del producto va tomando una a una las tarjetas marcadas como
terminadas, las detalla y muestra con ayuda de los miembros del
equipo. Este sistema se utiliza mucho; 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 una opción de uso
totalmente funcional y gratuita, es Trello,que no solo se comporta como las
tarjetas, sino que se ve igual a un tablero de fichas; así puedes seguir la
misma dinámica, pero en un formato digital. Otro programa que
probablemente te sorprenda porque está muy vinculado al desarrollado en
cascadas, pero que ha tenido importantes avances, es Jira; al punto de que
hoy en día es uno de los programas más populares para gestionar equipos
Scrum. Jira, a diferencia de Trello, es un servicio que se cobra
mensualmente. Finalmente, otro programa de suscripción de pago es Pivotal
Tracker, con funcionalidades similares, y mi favorito personal, porque
permite integrar las tareas con repositorio de código. Además, puedes
utilizar las estimaciones para hacer proyecciones para el tiempo aproximado
de entrega, y hasta planificar varios sprintspor adelantado. Pero sin importar
la herramienta que utilices para administrar tu proyecto de Scrum, recuerda
que la simplicidad y transparencia lo son todo.Cualquier herramienta que
uses debe ser para simplificar y ayudar a generar visibilidad, y nunca para
complicar los procesos.

Buenas prácticas con Scrum

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 de la lista de
producto. En este punto el dueño del producto 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 ese 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 junto a la visión de producto, que es la proyección hacia el
futuro que tiene el dueño del producto 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 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 esa 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 de Scrum es tratar de solucionar todos los problemas
encontrados en el mismo sprint en que se detecta, 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, las tareas 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 a problemas y confusiones más adelante. Cada historia debe
examinarse a conciencia en presencia del dueño del producto para que
aclare todas las dudas, y también con el equipo, para que antes de hacer el
cálculo pueda definir al menos de manera básica cuáles serán los pasos, los
procesos y las herramientas necesarias para concluir esta tarea, y también
para identificar dependencias, problemas potenciales y posibles riesgos.Este
proceso toma tiempo, dedica unos 30 minutos por cada tarea. Parece mucho
tiempo, pero es mejor invertir media hora planificando que días completos
corrigiendo una tarea que no fue bien interpretada. Otra buena práctica es
dejar muy clara la definición de "Terminada" de cada tarea. Si solo nos
encargamos de cumplir con lo que se pide sin analizar los alcances, los
conflictos, las dependencias y posibles errores encubiertos, solamente
estamos trabajando a medias,generando deuda técnica y retrasando el
proyecto a largo plazo. Dejar tareas sin que estén totalmente terminadas es
una bomba de tiempo que tarde o temprano va a explotary afectará a todo
el proyecto.Por eso es crucial definir un criterio de aceptación en cada
tarea, solicitar pruebas de regresión para garantizar que los cambios
implementados no generan conflictos en ninguna parte y asegurarse de que
todos los involucrados en la tarea ejecutarán algún tipo de proceso de
control de calidadpara garantizar que no se agregan nuevos
problemas.Finalmente, te recomiendo automatizar el proceso de control de
calidad todo lo posible. Esto te permite confirmar que cumples con todos los
criterios de aceptación actuales, y de paso puedes garantizar que no
aparecen nuevos problemas sobre las funcionalidades antiguas.

Siguientes pasos con Scrum

Llegamos al final de este curso de los roles de Scrum. Llegados a este punto,
ya conoces no solo la descripción de cada rol,sino la filosofía que está detrás
de cada uno de ellos y cómo se relacionan entre sí durante todos los rituales
de Scrum. A lo largo de este curso, aprendimos que Scrum es un
framework que te ofrece un marco para implementar diferentes técnicas y
métodoscon 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.Aunque 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 proyecto, 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.orgdonde podrás
consultar los programas, los horarios, la disponibilidad y los costos del
proceso de certificación.