COLABORANDO CON SCRUM

Sincronizando equipos tradicionales (en el mejor de los casos) con equipos Scrum

Sergio Fernández (@artabricus)

"Lo que tenemos aquí es un problema de comunicación."

La leyenda del indomable (1967)

 

Debo confesar que la famosa frase de la "Leyenda del indomable" con la que doy arranque a esta entrada del blog no la descubrí realmente por la genial película de Paul Newman, sino que llegó a mi a través de los Guns n' Roses y su no menos magnífico "Civil War". Esa canción la escuchaba mucho (muchísimo) hace ya (algunos, no tantos) años en mis tiempos de universitario cuando intentábamos organizarnos unos pocos alumnos para hacer una simple práctica de la asignatura de Programación.... pues eso, que eramos pocos y teníamos (muchos) problemas para trabajar en conjunto, ¿cuál era el problema?, la comunicación, las diferentes necesidades, las distintas capacidades de los miembros del equipo.... en una gran organización el problema es el mismo, pero claro.... mucho peor.

Aunque mi propósito es plantear este artículo como una primera aproximación (algo superficial, me temo) a la problemática de la sincronización de equipos Scrum con otros funcionando bajo otras metodologías, este problema no es muy diferente del que existen entre grupos o departamentos indistintamente de la tecnología que estén empleando. De hecho, cuando existen equipos Scrum implicados el problema es menor, puesto que el carácter flexible con respecto a las funcionalidades a implementar dentro de un proyecto Scrum facilita en extremo la adaptación a las necesidades de otros grupos mas rígidos. 

En definitiva, el problema consiste en como establecer relaciones Win2Win (Ganar-Ganar) entre los diferentes equipos colaborando dentro de la organización. Desde mi punto de vista existen seis puntos de acción sobre los que se puede trabajar para mejorar estas relaciones, estos son:

  • Sincronización.
  • Verificación.
  • Visualización.
  • Incentivos.
  • Adaptación.
  • Polinización.

 

Sincronización

Obviamente, el primer paso para la colaboración entre equipos es la sincronización. Esta actividad no solo es importante en entornos donde distintos equipos colaboran, sino que tiene gran importancia en equipos aislados, y todas las metodologías proporcionan mecanismos más o menos complejos para conseguir esta sincronización. En equipos siguiendo metodologías waterfall se consigue mediante el plan, que indica en todo momento en qué actividad está cada miembro del equipo, las próximas actividades y las dependencias entre las mismas. En equipos que se rigen por el uso de técnicas Agile como Scrum, la sincronización se hace a través de los Daily Meetings y el Sprint Plan. Cuando tenemos múltiples equipos la sincronización se vuelve más compleja y, si cabe, más importante. Existen múltiples técnicas, en este blog mencionaremos algunas de las más populares.

Una técnica básica para la sincronización entre equipos que comparten el código que están generando es la Integración Contínua, el facilitar la construcción de forma frecuente (al menos diaria) y la ejecución de pruebas básicas sobre dicha construcción, constituye una técnica básica para sincronizar a los equipos en función del código que van generando. Cuando estas construcciónes son diarías suelen recibir el nombre de Daily (o Nightly) Builds y a los tests ejecutados Smoke Tests.

A veces estas construcciones diarias constituyen una fuente continua de ruido, debido al gran número de interdependencias en los equipos. Una técnica habitual desde el punto de vista de la arquitectura de los sistemas a emplear en este caso suele ser el diseño en Matriz del sistema. Esto es, en la etapa inicial se definen e implementan los interfaces entre los distintos equipos, una vez probados, estos se congelan permitiendo a los equipos trabajar ya por separado y de forma autónoma (esta es una técnica empleada con gran éxito en el caso de Spotify1).

Cuando se trata de sincronizar las entregas de distintos equipos, una técnica muy efectiva suele ser la construcción de Release Trains, consistente en la planificación de distintos trenes en los que cada uno de los equipos introducen antes de su "partida" las funcionalidades ya terminadas. Esta técnica es especialmente efectiva si se combina con las dos anteriores. Un desarrollo detallado de los Release Trains puede encontrarse, por ejemplo, en el framework SAFe 2,3

 

Verificación

Siguiendo la filosofía ágil de medir todo lo que se desea mejorar, es pieza fundamental en la colaboración el establecer medidas o puntos de control dentro de la colaboración entre los departamentos. Uno de las primeras incognitas a despejar llegados a este es la de quien debe ser la persona/s que deben medir e interpretar los resultados de la colaboración. Es indispensable crear la figura del "Facilitador" de la colaboración, esto puede ser una persona o un equipo, y que tendrá las siguientes responsabilidades:

  • Establecer las pautas de coordinación entre los distintos grupos.
  • Medir el progreso de la colaboración.
  • Eliminar los obstaculos e impedimentos.
  • Alinear las relaciones.

Es decir, es necesario crear la figura de un Scrum Master (o Scrum de Scrum Masters) para la relación de colaboración. Este "Facilitador" establecerá los puntos de control o "check points" dentro del funcionamiento de los diversos grupos para poder gestionar las dependecias entre equipos, detectar (y anticipar si es posible) los riesgos y problemas, y determinar (valorar) el funcionamiento de la colaboración.

 

Visualización

La visualización constituye otro de los pilares fundamentales de la filosofía ágil. Para conseguir una colaboración efectiva es imprescindible que la información fluya entre los departamentos/grupos que necesitan colaborar. Existen múltiples mecanismos y técnicas que pueden facilitar la compartición de esta información, un tablero o panel Kanban en una sala de reuniones común a los distintos equipos puede ser una solución perfecta si los equipos se encuentran localizados en la misma ubicación geográfica, así mismo, esa sala constituiría un lugar perfecto para establecer reuniones para realizar el seguimiento del estado de la colaboración (dependencias, riesgos, impedimentos, etc...). En el caso de que la distribución geográfica de los equipos no permita una solución tan sencilla, es posible sustituir estos tableros físicos por tableros on-line o en la nube para lograr este propósito. Otras soluciones para compartir la información serían mediante el uso de Intranets, Redes Sociales Coorporativas, Blogs, etc...

 

Incentivos

Es importante conseguir que no solo el coordinador o facilitador de la coordinación sea el único actor involucrado o preocupado por el buen funcionamiento de la colaboración. Hay que intentar que otros miembros (sino todos) actúen y sean participantes activos de la colaboración. El "buen" trato de los incentivos puede constituir un elemento importante para fomentar la colaboración entre los equipos.  Hay que tener cuidado con el manejo de los incentivos, puesto que habitualmente (demasiado) actúan en la dirección opuesta, dificultando la colaboración, aumentando los individualismos y fomentando la competencia (insana) entre departamentos o grupos de trabajo que deberían tener (y tienen) un objetivo común dentro de las organizaciones.

En el libro de Bjarte Bogsnes "Implementing Beyond Budgeting"4 se presenta un exhaustivo análisis sobre el establecimiento de objetivos e incentivos dentro de equipos de trabajo ágiles y su lectura es altamente recomendada. A modo de resumen se podría decir que:

Los objetivos deben ser "inteligentes"/"smart", es decir:

  • Specific. Específicos.
  • Measurable. Medibles.
  • Achievable. Alcanzables.
  • Relevant. Relevantes.
  • Time bound. Acotados en el tiempo.

Los incentivos asociados a dichos objetivos, deberían cumplir algunas reglas también:

  • Asociados a equipos, no a personas.
  • No necesariamente deben ser económicos.
  • Asociados al reconocimiento público.

 

Adaptación

Otra estrategia a aplicar para fomentar la colaboración es intentar acercar las metodologías de cada uno de los equipos mediante un enfoque iterativo. Este ejercicio resulta muchas veces extremamente complejo y puede producir rechazos por parte de los equipos si no se realiza de forma correcta. El enfoque adaptativo normalmente resulta en definir microproyectos cada uno de ellos siguiendo la metodología propia de cada uno de los grupos, pero cumpliendo una forma de trabajo "de nivel superior" orientado a entregas frecuentes y al uso de técnicas de sincronización ya mencionadas aquí como los Release Trains.

Esta aproximación tiene cierta similitud con enfoques metodológicos complejos como el modelo en Espiral o frameworks agile complejos como SAFe. Requiere una experiencia muy alta por parte del facilitador para definir esta estrategia y que además cuente con un respaldo muy fuerte por parte de la organización para evitar los rechazos.

 

Polinización

Finalmente, todos estos esfuerzos desde el punto de vista colaborativo generan un valor que facilita en si mismo el éxito de la colaboración. Esto es la polinización, el trabajo en conjunto de equipos con distintas visiones, estrategias y metodologías, permite que los miembros de dichos equipos asimilen de forma "inconsciente" ciertas "best practices" o formas de trabajar de otros grupos, y las puedan introducir de forma natural en sus propios equipos. Esta polinización puede "dirigirse" por parte de la propia organización intentando mostrar de forma mas relevante o pública la forma de trabajar de algunos de los equipos en cuestión (esto resulta especialmente útil cuando se está introduciendo una nueva metodología dentro de la organización). Se pueden aplicar diversas técnicas para intentar exponer como trabajan los grupos con mejor rendimiento o que utilizan la metodología "target". Esto puede hacerse a través de múltiples mecanismos como:

  • Participación en reuniones o ceremonias de otros equipos.
  • Tracer Bullet (the pragmatic programmer).
  • Presentaciones, workshops,...

Con todo ello se busca introducir mediante un mecanismo poco agresivo la cultura, la metodología o las prácticas que se quieren incorporar dentro de la empresa o de la colaboración entre los distintos equipos.

 

 

Referencias


1. [Spotify 2014] Spotify Team. "Spotify Engineering Culture". https://www.youtube.com/watch?v=Mpsn3WaI_4k

2. [SAFE 2015] Leffingwell et al. "Scaled Agile Framework". http://www.scaledagileframework.com/ 

3. [LEFF 2011] Leffingwell, Dean. "Agile Software Requirements". Addison-Wesley 2011.

4. [BOGSNES 2009] Bogsnes, Bjarte. "Implementing Beyond Budgeting". Wiley 2009.

 

 

Deja tus comentarios

Enviar un comentario como invitado

0

Gente en la conversación