Mi guía de Scrum distribuido para descargar (en español).

1. SCRUM DISTRIBUIDO
AUTOR: RAÚL GARCÍA CARDOSO
INTRODUCCIÓN
Esta guía hace un repaso a los principales factores a tener en cuenta cuando trabajamos con equipos distribuidos utilizando
metodologías ágiles.
Está basada en el uso de Scrum como metodología principal, y de ahí que muchos de los puntos que se trataran estén
enfocados a sus diversos puntos focales, pero pese a estás especificaciones más detalladas, puede servir de punto de
partida para el entendimiento de las diferentes buenas prácticas en cualquier contexto de desarrollo ágil.
Los puntos de los que hablaré están agrupados del siguiente modo:
 HABILITANDO LA COMUNICACIÓN
 CONSTRUYENDO CONFIANZA
 BUENAS PRACTICAS
o ASPECTOS TÉCNOLOGICOS
o ROLES
 PRODUCT OWNER
 SCRUM MASTER
 EQUIPO
o EVENTOS
 PLANNING
 DAILY
 REVIEW
 RETROSPECTIVE
o ARTEFACTOS
o REFINAMIENTO DEL PRODUCT BACKLOG
o SCRUM OF SCRUMS

2. Scrum Distribuido
2
HABILITANDO LA COMUNICACIÓN
Los mayores desafíos en el trabajo con equipos distribuidos se centran en las cuestiones humanas, y estas empiezan por la
comunicación. Entonces, ¿cómo podemos asegurar que las comunicaciones sean efectivas?
Los modos de comunicación se pueden colocar en una escala de "riqueza" similar a esta:
La gran fuerza del correo electrónico es que no depende de que ambas partes estén presentes simultáneamente, y además
conserva un registro de la discusión que se puede referenciar más tarde, pero la gran desventaja es que a menudo necesita
mucho más tiempo y esfuerzo. Por eso en los entornos de equipos distribuidos debemos alejarnos del correo
electrónico como principal medio de comunicación, haciendo que la comunicación en vivo tan fácil como sea
posible.
- El propio equipo debe estar de acuerdo en que, siempre que sea posible, las conversaciones deben realizarse
en vivo en lugar de por correo electrónico. (Si la conversación necesita ser documentada, cualquiera de las partes
puede enviar después un breve resumen por correo electrónico).
- Es importante que se comunique claramente al equipo que es aceptable llamar por teléfono con preguntas
rápidas y urgentes sin necesidad de pre-programarlas. (de lo contrario, muchos equipos asumirán que no está bien
llamar y se predeterminarán al correo electrónico).
- Los medios de contacto (teléfono, mensajería instantánea, etc) de todo el equipo (especialmente del propietario del
producto) deben colocarse en una ubicación compartida (wiki). Incluso junto con horas aceptables en las que poder
contactar con temas urgentes en horario fuera de la oficina.
Hacer más fácil la comunicación telefónica es un paso importante, pero no es suficiente. Todas las reuniones clave de
Scrum deben realizarse visualmente. Los problemas con las reuniones sólo de audio son muchos:
- Se pierden las expresiones faciales y el lenguaje corporal.
- No está claro qué voz pertenece a qué persona.
- A menudo falla el "flujo" natural y la cadencia de la conversación cuando hay interrupciones involuntarias, o cuando
la gente tiene miedo de hablar por miedo a interrumpir.
- Sin embargo, las disfunciones más significativas en las llamadas de voz se producen por las personas
"multitarea".

3. Scrum Distribuido
3
CONSTRUYENDO CONFIANZA
El otro factor clave (o restricción) para los proyectos distribuidos radica en cuánta confianza existe entre los miembros del
equipo (propietario del producto incluido).
Para fomentar esa confianza, uno de los pasos más importantes para el éxito de un proyecto Scrum distribuido, es que los
equipos se reúnan en persona al principio y pasen juntos tiempo de calidad compartiendo información clave del
proyecto y construyendo una relación entre sí, proporcionando también información acerca de los valores, las actitudes y
la mentalidad del propietario del producto y los miembros del equipo. Y para que sea realmente útil, se deben planificar
salidas informales lejos de la oficina, para tener la oportunidad de interactuar no sólo como compañeros de trabajo sino como
personas, sentando las bases para salvar algunas de las diferencias culturales entre los dos lugares.
También es importante volver a reunirse cada 3-4 meses, o después de conseguir ciertos logros, para volver a hacer
hincapié en los objetivos que se ponen en marcha a partir de ese momento. En general sirve para volver a sincronizar los dos
lugares entre sí y fortalecer la idea de un objetivo común y la mentalidad de "un solo equipo".
La segunda parte en la construcción de una relación de confianza, se basa en desarrollar la transparencia y la honestidad
entre sus miembros. Los equipos a menudo temen ser abiertos con el Propietario del Producto (especialmente si esa
persona es el cliente), por si este estará molesto o decepcionado si le plantean una dificultad o preocupación, o por si su
incertidumbre será percibida como incompetencia. Como resultado, muchos equipos invierten una cantidad significativa de
esfuerzo en tratar de crear la apariencia de que todo va bien. Debemos ser conscientes de que cuanto más tardamos en
arreglar las cosas, más esfuerzo se invierte en mantener la apariencia de que no pasa nada, esfuerzo que, irónicamente,
sería mucho mejor empleado tratando de resolver el problema.
Entonces, ¿cómo se puede evitar este síndrome? El Propietario del Producto debe comunicar al equipo en términos
inequívocos que quiere escuchar tanto las buenas noticias como las malas, que nadie será castigado por ser
honesto, y que la única pregunta "tonta" es la pregunta que no se pregunta. Tras esto, el Propietario del Producto debe
invitar constantemente al equipo a hacer preguntas y plantear preocupaciones, respondiéndolas de la manera más positiva y
lo más orientadas a la solución posible.
Para establecer una base de confianza al comienzo de una relación de trabajo de larga distancia, puede ser muy útil tener
una conversación abierta y directa sobre lo que cada uno se compromete a hacer y lo que cada uno espera que el
otro haga.
Algunos ejemplos reales de estos compromisos entre los equipos Scrum son:
- Nos comprometemos a ser honestos unos con otros. Si tenemos una preocupación, una duda o si vemos un
problema, nos comprometemos a exponernos inmediatamente.
- Si no estamos contentos con algo que ha sucedido, o algo que otro ha hecho, nos comprometemos a exponer esto
de inmediato el uno al otro.
- Nos comprometemos a no escalar un problema a la alta dirección sin primero tratar de resolverlo entre nosotros. Y si
se hace necesario el escalado, nos comprometemos a hacerlo saber por adelantado para que no sorprenda a nadie.
- Reconocemos que la gente comete errores y tiene malentendidos, pero que lo importante es encontrar y corregir el
error o el malentendido lo más rápido que podemos.
BUENAS PRÁCTICAS
ASPECTOS TÉCNOLOGICOS
Es muy importante que todos los miembros del equipo tengan el mismo entorno de desarrollo para eliminar ambigüedades y
reducir los problemas causados por las inconsistencias entre las ubicaciones.

4. Scrum Distribuido
4
La práctica de la integración continua es extremadamente provechosa. El código nuevo o modificado se integra
temprano y a menudo, activa un ciclo de compilación y prueba automatizada, permitiendo que los problemas de
integración sean más pequeños y manejables y puedan ser detectados y corregidos inmediatamente. Es muy
importante tener la disciplina de resolver los problemas inmediatamente, y muchos equipos están de acuerdo en
convenciones tales como, "no se puede dejar la oficina con una compilación fallando". La última cosa que los desarrolladores
en el otro lado del mundo quieren es comenzar su día con este problema.
Cuando el equipo se divide físicamente, las herramientas de comunicación en tiempo real cobran una importancia crítica.
Como mínimo, los equipos requieren lo siguiente:
- Clientes de mensajería instantánea (para comunicarse y para indicar su presencia al resto del equipo).
- Auriculares y Webcams.
- Herramientas para compartir el escritorio.
- Wiki para compartir detalles del proyecto, información personal de cada miembro del equipo (email, MI, VOIP, áreas
de especialización, horas de trabajo típicas), listas de email, calendario con fechas de sprints y releases, fiestas
locales, vacaciones, etc.
- Sistemas de alerta sobre el estado de las compilaciones y los errores.
EL PRODUCT OWNER
En equipos distribuidos se vuelve aún más importante tener un propietario de producto activamente involucrado y
comprometido. A menudo, las organizaciones seleccionan a un individuo en la misma ubicación que el equipo y lo colocan
en el rol de "Proxy Product Owner", para proporcionar orientación al equipo cuando el propietario del producto real no
está disponible. Esto puede funcionar, pero a menudo trae consigo un nuevo conjunto de desafíos. Si hay un PPO
trabajando con el equipo, probablemente es importante mantener un flujo diario de preguntas y respuestas entre el
equipo y el "verdadero" Propietario del producto, o hacer que ScrumMaster compile y envíe al final del día una lista de
preguntas abiertas, que idealmente el Propietario del Producto podrá responder cuando el equipo regrese a la oficina al día
siguiente.
EL SCRUM MASTER
Al igual que con el PO, el papel del ScrumMaster se vuelve aún más crítico en un proyecto distribuido porque las
"disfunciones de distancia" requieren un compromiso aún más activo y tenaz con la transparencia, la inspección y la
adaptación.
Si el PO está en un lugar y el equipo está en el otro, el ScrumMaster debe estar ubicado donde está el equipo, puesto que
de otro modo, los deberes críticos del ScrumMaster de entrenar, ayudar a eliminar impedimentos y proteger al equipo de
interrupciones estarían esencialmente ausentes.

5. Scrum Distribuido
5
EL EQUIPO
Cuando el equipo se divide entre múltiples ubicaciones, los desafíos del desarrollo a menudo se multiplican. El nivel de
coordinación, cooperación y trabajo en equipo es aún más exigente. Por eso se requiere un compromiso real y una
inversión significativa en las relaciones de trabajo, habilidades y herramientas utilizadas por los distintos miembros del
equipo para lograr un alto nivel de éxito.
Como hemos dicho antes, para empezar, los miembros del equipo normalmente necesitarán pasar períodos de tiempo
trabajando juntos, especialmente al comienzo del proyecto. Una excelente práctica es que el equipo se junte durante el
primer Sprint del proyecto (o idealmente durante los dos o tres primeros), para permitir a los desarrolladores construir
relaciones de trabajo entre ellos, así como afianzar la confianza y la visibilidad en las habilidades (fortalezas y debilidades) de
los demás. Pudiendo además, desarrollar el conjunto de acuerdos de trabajo, como los estándares para su "definición de
hecho", los convenios de una codificación de calidad, así como otras prácticas de desarrollo, herramientas, horas de trabajo
superpuestas y otras necesidades.
Además, los equipos distribuidos que tienen éxito con Scrum suelen tener algún tipo de "embajador", donde los miembros
del equipo viajan constantemente a la otra ubicación por períodos de tiempo para trabajar con sus colegas lejanos. La
objeción inmediata a este viaje constante es "¡costará dinero y tiempo!". Y la respuesta es simple: Sí, pero es más barato
que la alternativa, la cual va a obtener mucho menos valor comercial para el proyecto. Sin el contacto cara a cara y
relaciones de trabajo de alta calidad, el equipo producirá menos software, software de menor calidad o funcionalidad que
será menos adecuada para las necesidades del cliente, o las tres.
Una disfunción común cuando los equipos se dividen entre dos lugares y no están adecuadamente unidos, es que el
equipo realmente funciona como dos equipos, pudiendo dar lugar a la desconfianza y el conflicto. Para evitar esto,
en lugar de tratar de trabajar como un solo equipo, puede ser más eficaz formar en equipos independientes de
Scrum, uno por ubicación, y tan poco acoplados entre sí como sea posible. Cada equipo debe ser completamente
funcional y debe ser responsable de producir piezas completas de funcionalidad, no simplemente hacer una
actividad particular (codificación, pruebas, etc.).
SPRINTS
Debido a los problemas de comunicación entre los participantes de diferentes lugares, es mucho más común descubrir
requisitos incomprendidos cuando llegamos a la Sprint Review. Por eso es conveniente tener Sprints no demasiado largos (2
semanas) y enfocarse inicialmente en dominar la capacidad de entregar incrementos de producto potencialmente
entregables al final de un Sprint.
PLANNING
Uno de los conflictos más habituales en equipos de Scrum distribuido es la superposición de horario. Un enfoque que puede
ayudar es dividir la reunión más larga (Sprint Planning) en varias sesiones más cortas en el lapso de dos días. Si hay días en
que parte del equipo se quede más tarde para realizar las reuniones, es importante que mantengan una jornada de trabajo
razonable llegando a la oficina más tarde de lo normal.
DAILY
Lo ideal es celebrar la Daily en vivo cada día a través de webcam, en una hora de trabajo superpuesta para ambos
equipos. Si el equipo está separado del propietario del producto, suele ser habitual que el SM simplemente envíe un correo
electrónico al PO informando acerca del Sprint Burndown Chart, en lugar de incorporar al PO a las reuniones diarias.
- Si el horario de la reunión es un inconveniente para un lado del equipo, es muy importante rotar la carga de
la inconveniencia de un lado a otro cada una o dos semanas.

6. Scrum Distribuido
6
- Si no es posible mantener la reunión diaria de forma conjunta, lo conveniente es mantener una reunión en cada
ubicación a la hora conveniente, y escribir un resumen de la misma para informar del estado (por correo electrónico)
a un miembro del equipo de la otra ubicación para que este lo comente al comienzo de su reunión diaria.
REVIEW
En un Scrum distribuido, las funcionalidades pueden ser menos "correctas" la primera vez que se muestran, debido a
que la comunicación clara y completa entre el propietario del producto y el equipo se hace más difícil por la distancia. Pero
esta es una de las realidades del desarrollo distribuido y el propietario del producto debe tener en cuenta e incorporar este
aspecto al Product Backlog para contabilizar el remanente adicional que se necesitará para mejorar el producto. Por eso es
muy importante que la Revisión de Sprint se planifique para un momento en que todos los miembros del equipo puedan
participar.
RETROSPECTIVE
Cuanto más distribuido es el equipo, más dificultades puede haber - y por lo tanto, más completa y eficaz debe ser la reunión
de Retrospectiva. Los equipos más exitosos se centran en la mentalidad de "aprendizaje" que define Scrum,
identificando problemas lo más rápido posible aplicando una solución práctica en el próximo Sprint.
En lugar de agonizar sobre cuál sería la mejor manera posible de resolver un problema, se opta por pensar en cuál es la
solución más simple que podría funcionar para probarla cuanto antes en el próximo Sprint.
Además como ya se ha comentado antes, los Sprints de corta duración pueden acelerar estas mejoras, permitiendo ciclos
más rápidos de inspección y adaptación.
ARTEFACTOS
En un proyecto Scrum distribuido, se acostumbran a utilizar más artefactos escritos, pero esto no debe significar que sea
todo lo que se requiere. De hecho, a menudo significa que se necesitará más conversación entre el propietario del
producto y el equipo para lograr un entendimiento compartido eficaz. El detalle escrito adicional simplemente le da al
equipo una herramienta de referencia para responder preguntas cuando el propietario del producto no está inmediatamente
disponible.
Los equipos Scrum distribuidos deben buscar compartir una visión común y dividir el trabajo en pequeños paquetes que
sean más fáciles de inspeccionar y adaptar, reduciendo así la confusión y resolviendo antes los malentendidos.
Los elementos del Product Backlog deben ser cortos y fáciles de entender, con claras condiciones de satisfacción. Los
mockups pueden transmitir mucha información rápidamente.
Si bien las historias de usuario son un formato popular y eficaz para articular los elementos de la cartera de productos, los
casos de uso ligeros también pueden funcionar bien.
Algunos equipos encuentran que tener un despliegue continuo (de demostración) en el que el propietario del producto puede
revisar la funcionalidad diariamente puede ayudar a mantener a todos sincronizados y alineados para detectar antes posibles
malentendidos.
Debe regir la idea de "probar lo más simple que posiblemente podría funcionar, e inspeccionar y adaptar".

7. Scrum Distribuido
7
REFINAMIENTO DEL PRODUCT BACKLOG
Los equipos distribuidos encuentran particularmente importante dedicar tiempo durante el Sprint (típicamente 5-10% de
su disponibilidad) para trabajar con el Propietario del Producto en el refinamiento del Product Backlog.
Los elementos nuevos o modificados significativamente serán preestimados por el equipo, los elementos grandes con
mucha prioridad se dividirán en elementos más pequeños.
Los elementos que no están claros o que son demasiado grandes se pueden devolver al propietario del producto para
refinarlos más.
Además cuando se detecte un problema técnico, el equipo puede planificar un "pico" dentro de un próximo Sprint para
hacer la investigación técnica correspondiente y obtener el suficiente entendimiento para estimar e implementar
posteriormente el ítem cuando llegue el momento.
SCRUM OF SCRUMS
Hay tres técnicas comúnmente utilizadas para coordinar los esfuerzos de equipos Scrum distribuidos, todos los cuales
pueden llegar a usarse juntos.
- La primera es permitir y fomentar la comunicación informal entre los miembros de los diferentes equipos. Esto a
menudo se pasa por alto, pero es una de las herramientas más poderosas para la eficacia del día a día.
Cuando un equipo o miembro del equipo está bloqueado por el otro equipo, su primer paso debe ser llegar a alguien
de ese equipo, y esto debe hacerse lo más fácil posible. Debe haber una Wiki a la que todo el mundo en el proyecto
tenga acceso y que incluya la información que se ha comentado en puntos anteriores.
- La segunda técnica es Scrum of Scrums. Esta es una práctica donde al menos un representante de cada equipo
se reúne con los representantes de los otros equipos en un horario regular (normalmente 2-3 veces por semana,
pero podría ser diario si es necesario) para informarse mutuamente sobre el progreso del trabajo y resolver posibles
impedimentos derivados de las dependencias entre equipos. Sirve para tomar decisiones técnicas transversales y
para proporcionar un foro de visibilidad entre proyectos.
Cuando los equipos se encuentran en zonas horarias significativamente diferentes, es importante que el horario de la
reunión de Scrum of Scrums sea cambiado periódicamente.
- La tercera técnica consiste en establecer "comunidades de práctica" para permitir a los miembros del equipo con
especialidades particulares trabajar más allá de los límites del equipo y ayudar así a guiar la dirección y evolución
del proyecto.
Estos grupos se crean de forma autónoma y se auto inspeccionan, adaptan y determinan su frecuencia de reuniones.
REFERENCIAS
Esta guía es un refinamiento o vuelta de tuerca si se le quiere llamar así, aportando mis apreciaciones personales y matizaciones, del
artículo original sobre Scrum Distribuido que puede encontrarse en:
http://www.goodagile.com/distributedscrumprimer/index.html