h1

Una Guía Práctica al Scrum Distribuido

02/02/2011

Wizbook [Icon By Buuf]  Libros.

Reunirnos es un comienzo.
Mantenernos juntos es un progreso.
Trabajar juntos es el éxito.

Henry Ford (1863-1947), industrialista estadounidense, fundador de la compañía automotriz Ford Motor Company.

En estos días tuve que ir al corporativo en San Diego para definir parte de la estrategia de desarrollo y mantenimiento que llevará nuestra área durante el presente año. Dicha estrategia incluye la colaboración de equipos distribuidos en San Diego (EEUU), Ciudad de México (México) y Nueva Delhi (India) debido a que en estas tres ciudades tenemos por separado la operación, desarrollo, mantenimiento y pruebas sobre los múltiples sistemas que tenemos bajo nuestra responsabilidad. Esto, aunado a que estamos usando una metodología ágil de desarrollo, me impulsó a leer un libro llamado “Una Guía Práctica al Scrum Distribuido” (A Practical Guide to Distributed Scrum) de la IBM Press. En esta guía los autores identifican los beneficios, retos y muchos trucos relacionados a la coordinación a través de Scrum de equipos de trabajo distribuidos; en los diversos capítulos del libro nos muestran puntos específicos a considerar durante cada una de las etapas de la metodología, como la planeación del Scrum, las reuniones diarias o las retrospectivas que se llevan a cabo al final de cada iteración.

Inicialmente el libro nos da una pequeña introducción a Scrum, cómo ha ido evolucionando y cuáles han sido las experiencias por parte de IBM y sus filiales con dicha metodología; cómo es que al tener equipos trabajando en diferentes horarios alrededor del mundo es posible acelerar la “salida a producción” y cuáles son los tipos de equipos distribuidos que es posible encontrar:

• Equipos colocados, donde todos los miembros están situados en una misma locación física. Estos equipos son los más referenciados por la metodología original y conforman la modalidad “ideal” de organización.

• Equipos colocados parcialmente, donde los miembros se encuentran en la misma locación física, aunque de vez en cuando pueden colaborar de manera remota. Esta forma de trabajar es muy común cuando alguno de los integrantes del equipo labora desde casa o cuando un representante del equipo debe estar en las oficinas del cliente todo el día mientras los demás trabajan en un área común por separado. Éste último esquema es muy socorrido al manejar fábricas de software.

• Equipos distribuidos con horarios de trabajo que se traslapan, como es el caso de Ciudad de México y San Diego California, con una diferencia de dos horas (GMT-6 vs. GMT-8).

• Equipos distribuidos con horarios desfasados, como es el caso de Ciudad de México y Nueva Delhi, India con prácticamente 12 horas de desfasamiento (GMT-6 vs. GMT+5.5). De acuerdo a los autores, éste es el tipo de equipos con más retos por enfrentar; especialmente cuando cuestiones fuera del ámbito laboral como idioma y cultura están involucrados.

Así entonces, a partir de las tres modalidades de equipo distribuido, el resto del libro proporciona consejos específicos a seguir para cada actividad.

Temas básicos: yo digo papa y tú dices patata

Uno de los principales objetivos de Scrum es facilitar la comunicación entre los stakeholders para minimizar el riesgo debido a suposiciones y malos entendidos durante el desarrollo. Por ello, unos de los principales retos a los que debe enfrentarse un equipo distribuido es el de generar y compartir ideas entre los miembros de forma alineada. En el libro se le da especial hincapié a cuatro ítems que por experiencia, son de hecho los más peliagudos en equipos con diferentes nacionalidades, culturas e idiomas:

• Los diferentes usos horarios y calendarios laborales. Un ejemplo muy común es que en Estados Unidos el lunch es de una hora y generalmente la gente lo toma al medio día; por usos y costumbres en la Ciudad de México la comida se toma de 2 a 4 de la tarde. Por ello conviene alinear horarios y definir en qué horas y fechas podemos y qué horarios están “fuera de límites” para evitarnos la mala experiencia de tener una reunión con el equipo líder a las 3:00 de la tarde del 16 de Septiembre (Día de la Independencia de México, día festivo nacional).

Diferencias de horario

En un proyecto distribuido siempre es conveniente desde un inicio definir las fechas y horas en las que estamos y no estamos disponibles. Esto para evitar dramas más tarde. (Fuente: Office Solutions and Tips @ McCombs School of Business, University of Texas at Austin)

• Diferencias culturales. Para aquellos que han trabajado con extranjeros esto es el pan nuestro de cada día, donde es necesario estar conscientes de otros puntos de vista y tomarse el tiempo para conocer a nuestros interlocutores. Un ejemplo es que en muchas culturas orientales, decir “no” es muy mal visto, por lo que muchos occidentales se han llevado un chasco al pedir retroalimentación con equipos del Sureste de Asia que jamás van a decir “no” a nada. El principal consejo que nos da el libro es buscar acercarse de manera más personal al resto del equipo. En el libro dan un buen ejemplo de cómo hacerlo:

En un equipo donde gente de Italia e India trabajaban juntos por primera vez, en Italia se organizó un almuerzo en grupo donde muchos voluntarios prepararon la comida. Durante la planeación del almuerzo, el equipo discutió el arreglo usual de cocina Italiana. Entonces, alguien tuvo la idea de pedir a los miembros del equipo Indio traer una muestra de su comida. Los miembros del equipo Indio se tomaron esto de corazón y cocinaron de forma casera una variedad interesante y deliciosa de comida. La comida India fue la más popular del día. Causó mucha plática, peticiones por recetas y conversación general y todavía sigue dando de qué hablar casi un año después del evento. Esto ayudó realmente a los equipos a conocerse un poco mejor de manera mutua. Este tipo de eventos pueden parecer triviales pero normalmente pagan grandes dividendos con relativamente poca inversión

— Andy Pittaway, IBM Global Services

A Practical Guide to Distributed Scrum. Woodward, et al. (IBM Press, 2010).

• Diferencias en el lenguaje. Para comunicarse efectivamente es indispensable que todos tengan la misma idea cuando ésta sea transmitida. Así como coger puede generar risas entre los Mexicanos o pingo puede sonrojar a los Peruanos, es necesario usar un lenguaje lo más plano posible, sin jerga o neologismos y tratar de disminuir en lo posible nuestros acentos. El libro recomienda entre otras cosas, permitir que todos hablen llamándolos por su nombre y preguntando si están de acuerdo o tienen algún comentario. El secreto reside en asegurarse que todos están hablando en los mismos términos; si alguien no tiene las habilidades requeridas para seguir la conversación, puede ser necesario traer un traductor o si es posible moderar la conversación, un servicio de mensajería instantánea o chat puede ser de gran ayuda.

• Dinámica telefónica. Aunque hablar por teléfono puede parecer trivial, cuando se realizan conferencias telefónicas entre un grupo de personas con diferentes acentos y nacionalidades es muy fácil perderse en el ruido. Por ello, en el libro incluyen algunos tips para facilitar una buena comunicación: desde lo más obvio como identificar al hablante o fomentar la participación de todos, hasta cuestiones técnicas como usar teléfonos dúplex y poner el “mute” si en nuestro lado de la línea hay mucho ruido de fondo.

Temas avanzados: Scrum de Scrums y compartiendo el dolor

El resto del libro describe qué es necesario considerar cuando existe un equipo distribuido en términos de todas las actividades encontradas a lo largo de la metodología:

• Planeación del Sprint
• Scrum diario
• Colaboración durante el Sprint
• Revisión del Sprint
• Retrospectiva del Sprint

Y donde se proporcionan algunas “reglas de oro” para llevar a cabo estas actividades, como de qué manera se puede estimar y construir el backlog, cómo identificar dependencias entre historias de usuario o cómo calendarizar las reuniones diarias con equipos completamente desfasados en horario laboral. Por ejemplo, para éste último punto puede ser necesario “compartir el dolor” al alternar los horarios de las reuniones, como tener una reunión a las 22:30 de México (10:00 AM del día siguiente en Nueva Delhi) mientras la siguiente se lleva a cabo a las 9:00 AM México (20:30 en Nueva Delhi).

Por otro lado, los autores ponen mucho énfasis en tres temas: integración continua, automatización de pruebas y desarrollo guiado por pruebas: estos tres enfoques son obligatorios para atacar un desarrollo distribuido y queremos seguir vivos para contarlo.

Conclusiones

Este es un buen libro para aquellos que ya conocen bien de qué se trata Scrum y han llevado algunos proyectos en modalidad colocada a buen término. Si es nuestra primera vez con Scrum y estamos lanzándonos al ruedo con una gestión de desarrollo distribuido de software, el libro puede ser un poco críptico ya que no tendremos un marco de referencia sobre el cual basarnos para saber cuándo estmos “metiendo las cuatro”.

Finalmente, un tip que he obtenido a través de la experiencia: cuando formemos equipos en Scrum conviene irse a los dos extremos: o todos colocados o todos remotos. Esto porque los equipos mixtos tienden a formar grupitos que excluyen a los que no están presentes. Un ejemplo bien claro lo tengo en mi propio trabajo: con cierta frecuencia tenemos que realizar reuniones telefónicas con gente en los Estates; ya que hay grupos de personas reunidos en dos salas, es muy común que en cierto momento alguien empiece a hablar de otro tema al mismo tiempo que el exponente principal, generando chacota y risas mientras los del otro lado se quedan con cara de “What?”. Si cada quien está conectado por separado desde su propia línea telefónica, la comunicación es bastante más fluida y como no hay “parejitas” secreteándose entre ellos, podemos tener una comunicación con mayor claridad, incrementando las probabilidades de éxito.

One comment

  1. […] distribuido. Esta modalidad del proceso es una historia aparte, pero baste decir que en un par de células, algunos miembros del equipo pertenecen a offshore. Es […]



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: