Facilitación: Fishbowl

El Fishbowl (o Pecera) es un formato de discusión grupal de origen gestáltico, ampliamente utilizado en contextos organizacionales y formativos.

Consiste en organizar un debate donde un grupo pequeño conversa en el centro mientras el resto observa, pudiendo integrarse al diálogo de manera fluida. 

Es ideal para grupos de tamaño medio cuando se necesita fijar un objetivo, aclarar situaciones confusas o analizar sistemas complejos.

Pasos

• Espacio: Coloca las sillas en dos círculos concéntricos. El círculo interior (la pecera) es para los participantes que inician el debate. El círculo exterior es para los observadores .
• Facilitación: La persona que facilita se sienta en el círculo interior y conduce la sesión mediante preguntas dirigidas a los participantes, sólo cuando sea necesario para avanzar.
• Inicio: El grupo interior debate el tema mientras el exterior escucha sin intervenir directamente.
• Intercambio: Deja una o más sillas vacías en el círculo interior. Cualquier persona del círculo exterior que quiera aportar puede ocupar una silla vacía y permanecerá hasta que su intervención haya sido escuchada y atendida. Quien facilita invita sutilmente a desocupar la silla a una de las personas que lleve más tiempo dentro del círculo central.
• Cosecha: Una o más personas toman nota de las preguntas, respuestas y temas clave que surgen en el diálogo, utilizando texto, esquemas, dibujos o gráficas para capturar la información.

Alternativas

Conversación en espiral: Una variante donde los participantes del círculo exterior rotan sistemáticamente hacia el interior, asegurando que todos tengan oportunidad de participar de manera equitativa.

Open Space Technology: Una metodología donde los propios participantes proponen y facilitan las sesiones de discusión sobre temas que les importan. Es ideal para grupos más grandes y cuando no hay una agenda predefinida.

Facilitación: Pros and contras

A la hora de evaluar métodos, procesos o soluciones a aplicar a un problema, un formato sencillo y rápido puede ser simplemente listar las alternativas y analizar los pros y contras de cada una.

Esto es algo que hacemos casi todo el tiempo, casi intuitivamente. 

Cuando usamos esta técnica como una manera de evaluar alternativas a una decisión participativa, generamos una mínima estructura sobre la que trabajamos en equipo. 

Por ejemplo:

Alternativa	Pros	Contras
A	Fácil de implementar Económica	Poco flexible Depende de otros factores Puede generar errores
B	Confiable Se adapta a otros casos No requiere entrenamiento	Lleva tiempo Alto costo
C	Se puede hacer en etapas No requiere supervisión Resultados inmediatos Adaptable	No está comprobada Sólo dos personas tienen conocimiento

Algunas alternativas para este tipo de análisis son:

• Que quien propuso una alternativa se enfoque en identificar sus contras, y que los demás busquen los pros (una manera de invertir el análisis natural)
• Trabajar en dos grupos, uno enfocado en los pros, y el otro en los contras, en una primera iteración, y alternarlos en la segunda
• Dividirse de a dos personas por alternativa, en la que una busca pros y otra contras, y se los debaten mutuamente, para anotar finalmente el resultado refinado
• En todos los casos, es importante que cada factor se discuta y se lo critique, para tratar de disminuir los sesgos de las personas que los identificaron

ScrumDay Guatemala 2024

Hace bastante que no publicaba nada en el blog, pero dejo esta entrada para compartir el contenido y la referencias de mi sesión "Excelencia Técnica para una Transformación Sostenible" dentro del ScrumDay Guatemala.

Aquí queda un link para descargar mis dibujos durante la charla (no usé slides, sino dibujos en vivo), y a continuación un montón de referencias útiles para quienes quieran profundizar:

Manifiesto Ágil y un resumen de la historia de su origen (en inglés)

Artículo sobre el paper original de Winston Royce describiendo Waterfall (cascada) y los malentendidos que hicieron que se tomara como un modelo recomendable durante décadas.

Artículo sobre Colaboración Real, que es uno de los puntos que usualmente falta en implementaciones de Scrum que no terminan de funcionar.

Artículo (en inglés) sobre Flaccid Scrum: una de las maneras de ver Scrum sin foco en prácticas técnicas. 

Video en donde dibujo y explico las prácticas de XP en 2 minutos. 

Artículo (en inglés) sobre Extreme Programming con links a los libros y más referencias.

Página de Extreme Programing en C2. Esta es la Wiki Wiki Web original (la primera de la historia), aunque en una versión modernizada.

Más artículos (en inglés) en el sitio de Martin Fowler sobre:

• Test Driven Development (TDD)
• The Practical Test Pyramid (los diversos niveles de automatización -o no)
• Continuous Integration
• Deployment Pipelines
• Continuous Delivery 

Hay multitud de recursos y fuentes para abordar estos temas. Le doy preferencia a los del sitio de Fowler porque tienen consistencia entre sí, confío en su curaduría (hay diversos autores pero están revisados por él) y siempre brindan multitud de referencias adicionales.

Habilidades de Scrum Master: Facilitación

Una de las habilidades principales a desarrollar como Scrum Masters es la de Facilitación.

La Facilitación como disciplina es independiente de la agilidad, y se origina alrededor de 1980 como una manera de resolver patrones tóxicos en reuniones de grupos en todo tipo de organizaciones. 

Algunos de estos anti-patrones incluyen:

• 
  Asumir que se llegó a acuerdos porque nadie se opuso a una decisión (aunque la mayoría de las personas participantes no hayan tenido la posibilidad de hacerlo)
• Presencia en la reunión sin posibilidad de participación activa, e incluso sin comprender el propósito de la reunión
• La pérdida de foco en el objetivo de la reunión, yéndose del tema, incluso dejando fuera de tema a una parte importante de las personas participantes

Como una manera de cambiar esta dinámica, surgió el rol de Facilitadora ó Facilitador.

Al asumir ese rol, nuestras responsabilidades pasan a ser:

• Previamente a la reunión
  
  
  
  
• comprender el objetivo final
• acordar con la o las personas que convocan que realmente quieren generar participación grupal y aceptar opiniones del resto del grupo
• diseñar las actividades y tiempos aproximados para lograr el objetivo
• colaborar en la convocatoria, incluyendo (si es necesario) la explicación de la dinámica de la reunión
• (mi sugerencia) asegurar que las personas invitadas sientan que pueden NO participar. Esto muchas veces implica un énfasis en que la no-participación es positiva si la persona invitada no siente conexión real con el tema.
  
  
• Durante la reunión
  
  
  
• Asegurar acuerdos mínimos de trabajo (respeto por todas las ideas, confianza en la inteligencia colectiva, apertura a escuchar posiciones contrarias)
• Explicar la dinámica y tiempos generales
• Guiar a través de cada una de las actividades, manteniendo los tiempos previstos
• Asegurar la participación de todas las personas (para esto se suele trabajar en grupos pequeños y luego hacer puesta en común; canalizar ideas por escrito o diagramas, además de hablando; variar tipos de actividad para mantener el interés, etc)
• Mantenerse tan neutral como sea posible (porque somos humanos, finalmente) sobre el tema en discusión. Cuando facilitamos, no participamos ni opinamos sobre el tema, y en cambio mantenemos el foco sobre la dinámica del grupo.
• Inspeccionar la interacción de las personas y adaptar el plan (que no debe ser demasiado estricto) para asegurar el mejor resultado posible.
• Asegurar la captura de elementos importantes del proceso y de las decisiones finales. Puede ser en formato de fotos, videos, audio, documentos, diagramas, etc.
• Lograr un cierre ordenado de la reunión, con una instancia mínima de reflexión sobre el funcionamiento general, oportunidades de mejora para próximas reuniones, posibles consecuencias o necesidades posteriores, etc.
  
  
• Después de la reunión
  
  
  
• Realizar una retrospectiva de la reunión con las personas que la convocaron, más allá del feedback del resto de las participantes.
• Compilar y preparar los contenidos generados durante la reunión para compartirlo con las personas participantes y otras que necesiten tener información del tema.
• Evaluar la necesidad de próximos pasos

En el contexto de Scrum, estas mismas responsabilidades se aplican a los eventos dentro del Sprint: Planning, Review y Retrospective.

¿Y la Daily Scrum? Como Scrum Master no es nuestra responsabilidad "facilitar" la Daily. Este evento es de y para Developers. Por supuesto, podemos colaborar en el inicio para que estas personas encuentren su propio formato y estilo hasta que les resulte útil. Más allá de eso, no deberíamos influir en el tema, más allá de evaluar con ellas si están teniendo o no problemas de coordinación, manteniendo el foco en el objetivo del Sprint y encontrando oportunidades de colaboración real. Si alguna de estas cosas no sucede, puede que la Daily no esté funcionando por completo, pero siempre será mejor buscar motivos sistémicos menos evidentes que tratar de ajustar una pieza mecánica, como el formato de la Daily.

Para profundizar más en el tipo de actividades que podemos utilizar en la Facilitación, veremos un modelo y algunos ejemplos en el siguiente artículo: el Diamante de Toma de Decisiones Participativa de Sam Kaner.

Eventos de Scrum: el Sprint

El Sprint es el ciclo principal de Scrum. Es la misma idea que en otros marcos es llamada Iteración, y en el caso de Scrum, su mayor importancia es que todo lo que Scrum describe está contenido dentro del Sprint.

También es el "timebox" principal que regula todos los demás.

La idea de TimeBox se utiliza en Scrum para el Sprint y todos sus eventos internos, y es lo que me gusta llamar una "restricción creativa". A primera vista parece una limitación, pero nos ayuda a mantener uno de los valores, que es el FOCO. Una vez que decidimos cuánto va a durar el Sprint de nuestro equipo, no podemos cambiarlo, y eso nos obliga a tener que aprender a entregar y organizarnos dentro de ese límite.

Según la Guía de Scrum, el Sprint puede durar un máximo de un mes, aunque en la práctica ya son muy pocos los equipos que mantienen Sprint de un mes, que suena a una eternidad. La duración más popular es la de dos semanas, pero es usual que los equipo más maduros prefieran el Sprint semanal.

La condición inicial para poder iniciar un Sprint es tener el Product Backlog listo para planificar el trabajo de todo el Sprint. Esto implica que al menos los Items del Product Backlog (o PBIs) más prioritarios estén lo suficientemente refinados.

La duración del Sprint es la que afecta a la vez el timebox máximo de cada uno de sus eventos interiores. Pero lo más importante es recordar siempre que todo sucede dentro del Sprint. Desde el punto de vista de Scrum, nada sucede fuera del Sprint.

Preguntas frecuentes acerca de los Sprints

¿Nunca se puede cambiar la duración del Sprint?

Sí, es posible hacerlo, pero con mucho cuidado. 

El motivo no debería ser circunstancial. Lo que no vale es cambiar arbitrariamente, agregando o quitando días por cualquier circunstancia, ni decidiendo en cada Sprint cuánto va a durar.

Personalmente encuentro solamente dos motivos para cambiar (en algún momento de la vida de un producto):

• Que el equipo intentó con una duración muy corta y no le resulta sostenible. Por ejemplo, intentaron Sprints de una semana y descubrieron que algunos temas técnicos o internos hacen que les resulte demasiado difícil entregar un producto funcionando al final de cada semana. En ese caso, luego de analizarlo en una Retrospectiva, podrían decidir decidir cambiar a Sprints de dos semanas (de ahí en adelante, sin seguir variando todo el tiempo).
  
  
• De forma similar, si el equipo comenzó con Sprints de dos o tres semanas y durante una Retrospectiva deciden que ya están lo suficientemente maduros como para hacer Sprints más cortos y así aumentar la frecuencia del feedback, podrían reducirlo (nuevamente, es importante que estén seguros de que será sostenible, para no tener que volver atrás).

En cualquiera de los dos casos, es importante que antes de cambiar la duración, tanto el motivo como la decisión sea comunicada a los stakeholders principales, más allá del Equipo Scrum, porque para quienes asistan a la mayoría de las Sprint Review, ese cambio de frecuencia es importante.

¿Se puede cancelar un Sprint antes de que termine?

Sí, es posible hacerlo, pero con mucho cuidado.

(No, no es déjà vu, la respuesta es la misma que la anterior. 😄)

Después de más de 10 años trabajando con Scrum, recuerdo presenciar un solo caso de cancelación, y era porque la compañía acababa de ser adquirida por otra, y no se sabía si el producto continuaría existiendo.

Los únicos motivos para cancelar un Sprint es que su Objetivo se vuelva totalmente obsoleto, por un cambio de negocio, mercado o tecnología tan enorme que cambia todo el contexto. Esto sucede muy raramente. Aunque la idea puede venir de cualquiera, la responsabilidad de cancelarlo (comunicándolo a todos los demás) es únicamente del Product Owner.