Un Equipo Offshore con un ScrumMaster Onshore, ¿Funciona?

July 24, 20144 min

Una pregunta que se hizo reciente en el Grupo de Profesionales de Scrum Certificados de Linkedin, describía un escenario común con el que la gente se encuentra cuando trabajan con equipos de Scrum distribuidos.

“El ScrumMaster y el coach de Scrum están onshore (cerca del cliente), mientras que los equipos de proveedores están offshore. ¿Se está el cliente engañando a sí mismo?”

La respuesta corta a esta pregunta es “Sí, el cliente se está engañando a sí mismo”.  Según mi propia experiencia y la de mis clientes que trabajan con equipos de Scrum distribuidos, la idea de que el ScrumMaster puede estar alejado del lugar donde se está realizando el trabajo es, en el mejor de los casos, una quimera.  En el peor de los casos, nos hace creer que un ScrumMaster es meramente un gestor de proyectos con un nuevo título que está presente en Scrum para supervisar al equipo y gestionarlo.  El rol del ScrumMaster es apoyar al equipo en su auto-organización, amplificar la contribución de cada miembro del equipo y apoyar el flujo de valor de principio a fin.  No es un trabajo que se puede realizar haciendo una llamada a través de una línea telefónica que funciona como puente.

Incluso aunque usted crea que un ScrumMaster tiene la responsabilidad de eliminar los obstáculos e impedimentos que tenga el equipo (que yo no lo creo así), entonces un fácil experimento de reflexión puede mostrar por qué este modelo distribuido no funcionará.  Si el ScrumMaster no está en la misma ubicación en la que está el equipo, ¿Cómo puede estar plenamente consciente de los obstáculos e impedimentos que el equipo está experimentando?  Los ScrumMasters deben estar presentes junto al equipo para ayudarles a identificarlos y para animar al equipo para que asuma la responsabilidad de resolver los impedimentos a medida que estos sucedan.  Un ScrumMaster que está ubicado en Michigan es completamente inútil para un equipo de Scrum que está ubicado en Shanghai, ya que no tiene ni idea de lo que está pasando cada día en el equipo.

Sin embargo, asumamos en aras de este experimento de reflexión, que el ScrumMaster, de alguna manera mágica, está consciente de los desafíos a los que se está enfrentando el equipo, en ese caso mi preocupación está basada en el hecho de qué es exactamente lo que va a hacer esta persona para eliminar los impedimentos.  Si tenemos al ScrumMaster en Portland, ¿Cómo va a eliminar los impedimentos a los que se enfrenta un equipo en Bangalore? ¿Cuál es el punto de partida para la organización offshore?  ¿Qué haría un ScrumMaster que está en los Estados Unidos para avanzar cuando haya algún tipo de retraso, aparte de enviar enérgicos correos electrónicos y frecuentes mensajes de buzón de voz  Incluso aunque el equipo de Bangalore fuera un equipo interno, por ejemplo, son empleados de la misma compañía para la cual también trabaja el ScrumMaster, ¿Cómo se adaptaría un ScrumMaster estadounidense a las políticas y procedimientos de una organización de Bangalore?  ¿Cómo navegaría la burocracia?

En mi opinión, el mundo de Lean ya ha resuelto este problema.  Las personas que practican Lean aprendieron hace mucho tiempo que una organización solo puede ser Lean si sus proveedores también lo son.  Si usted quiere conseguir realizar entregas rápidas de principio a fin usando el Pensamiento Lean, en algún momento necesitará enseñarles a sus proveedores lo que es el Pensamiento Lean.  Creo que podemos tomar prestada una página del libro sobre el Pensamiento Lean para aprender a cómo enfrentarnos a los desafíos de Scrum distribuido – capacite a sus empleados offshore sobre Scrum y apoye el establecimiento de ScrumMaster locales.  Proporcióneles entrenamiento sobre cómo hacer Scrum bien.  Si su compañía considera que Scrum es una buena inversión para su personal onshore, ¿Por qué la empresa se muestra reticente a hacer una inversión similar con sus propios empleados?

Puedo entender por qué una empresa elegiría no invertir en proveedores offshore.  Puede que piense que debería buscar el proveedor más barato; entonces, ¿para qué invertir dinero en algo que no es necesario?  Sin embargo, Scrum enfatiza la colaboración y si usted no está dispuesto a invertir para aumentar la capacidad de un proveedor clave que es responsable de la entrega de una parte crítica de su producto, entonces Scrum es el modelo equivocado para esta relación de negocios.  Simplemente enfóquese en una buena gestión del proyecto, en la gestión y el seguimiento de los riesgos del proyecto y en dirigir la entrega de estos equipos offshore de acuerdo a su plan.  Estará mejor siguiendo este modelo que intentando hacer que Scrum funcione en una mala relación de negocios.