Code & Beyond

Facilitación: BotStorming

2026-03-24T15:12:00.000-03:00

¿Estás buscando alternativas para un problema o desafío que tienes por delante?

Hoy día podemos utilizar Chats (con modelos de lenguaje), buscadores o sitios especializados para investigar rápidamente soluciones alternativas.

Esta actividad puede realizarse de varias maneras:

En solitario, en varios grupos o uno solo (dependiendo del número de personas)
Con un límite de tiempo claro

Si son varias personas o grupos en paralelo:

Coordinar mínimamente el nivel de detalle de lo que queremos saber de cada alternativa:
nombre
link o referencia
descripción breve
uno o más factores relevantes (por ejemplo):

Costo
Duración
Formato / Tamaño / Estilo
Disponibilidad
Ratings
Audiencia
etc

Dividiendo en varios sub-temas o aspectos por persona o grupo
Dividiendo entre varias tecnologías para cada persona o grupo

Facilitación: Reality Switch

2026-03-23T15:23:00.000-03:00

Esta es una técnica para generar ideas alternativas “saliéndose de la caja”.

La facilitadora (introduciendo al grupo en un escenario ficticio) explica que se ha instalado un switch (puede simularse con un marcador, con un dibujo en un papel, o con una foto si es un entorno virtual) que sirve para apagar la realidad.

Con la realidad apagada durante un tiempo determinado, los participantes podrán proponer alternativas sin límites de precio, tecnológicos, legales, morales o psicológicos.

La actividad consiste en generar ideas extremas o delirantes durante ese tiempo limitado (2 o 3 minutos suele alcanzar). Pueden ser anotadas en papeles físicos o virtuales (sin detalle, solamente un título descriptivo que permita comentarlos luego).

El propósito de este primer momento es que los participantes se diviertan, enciendan su imaginación y generen alternativas MUY lejos de la zona de confort y las respuestas “normales”.

Pasado el tiempo, realizamos una puesta en común y empezamos a pensar cómo algunas de esas ideas podrían “bajarse a tierra” y convertirse en alternativas posibles.

Cosas que suceden:

Ideas nuevas totalmente realizables, pero que no se veían antes
Alternativas muy extremas, pero que tienen versiones más sencillas
Ideas que implican una experiencia o beneficio que podemos lograr de otra manera
Opciones que parecen imposibles a simple vista, pero para las que algunos participantes encuentran alternativas (técnicas, de proceso, comerciales, etc)

Facilitación: SCAMPER

2026-03-20T15:02:00.000-03:00

SCAMPER es una técnica de brainstorming estructurado creada por Bob Eberle en 1971, como una manera estructurada de brainstorming. Eberle publicó la técnica en su libro Scamper: Games for Imagination Development con el objetivo de ayudar a desarrollar la creatividad de manera sistemática y accesible.

Utiliza una sigla para estimular la generación de ideas desde diferentes ángulos. A diferencia del brainstorming libre, SCAMPER ofrece una estructura clara basada en siete verbos de acción. Cada letra representa una pregunta disparadora que ayuda a explorar cómo mejorar un producto, servicio o proceso existente . Es especialmente útil cuando se busca innovar sobre algo concreto y se quiere evitar la dispersión.

Pasos

Objetivo: Elige un producto, servicio o proceso existente sobre el que quieras innovar y comunica el desafío de manera clara y directa.

Recorre cada letra de la sigla: Dedica un tiempo a cada categoría y genera ideas respondiendo a sus preguntas guía:

Sustituir: ¿Qué componentes, materiales o procesos podemos reemplazar?
Combinar ¿Qué podemos fusionar con otros elementos, funciones o servicios?
Adaptar: ¿Qué podemos tomar de otros contextos para ajustarlo a mi necesidad?
Modificar: ¿Podemos cambiar el tamaño, forma, color o atributos?
Proponer otro uso: ¿En qué otros contextos o mercados se podría utilizar?
Eliminar: ¿Qué podemos quitar o simplificar sin perder valor?
Reordenar: ¿Qué ocurre si invertimos el orden, los componentes o el proceso?

Cosecha: Registra cada aporte sin juzgar, fomentando la cantidad sobre la calidad .

Alternativas

SCAMMPERR: Una variante que agrega una segunda "M" (magnificar) y una segunda "R" (revertir), ofreciendo un mayor nivel de detalle en la exploración.

TRIZ: Una metodología basada en el análisis de patentes que utiliza principios inventivos para resolver contradicciones técnicas. Es ideal cuando se enfrentan problemas complejos con limitaciones técnicas aparentemente irreconciliables.

Crazy 8s: Un ejercicio de ideación rápida donde cada participante dibuja u escribe 8 ideas en 8 minutos. Es útil para generar volumen en poco tiempo y complementa bien la estructura de SCAMPER .

Facilitación: Brainstorming

2026-03-18T14:27:00.000-03:00

El brainstorming (o lluvia de ideas) es un método creado por Alex Osborn en 1938 para potenciar la creatividad en reuniones.

Funciona tanto en grupo como de forma individual, y su objetivo es atacar un problema desde múltiples ángulos generando una gran cantidad de ideas en un ambiente relajado, sin críticas, donde los participantes se sienten libres de expresarse y construir sobre las ideas de los demás.

Cómo funciona

Facilitación: Elige a la persona a cargo de explicar las reglas, mantener el ritmo y dinamizar el proceso.
Objetivo claro: Formula el propósito como una pregunta concreta (ej. “¿Cómo podríamos resolver…?”) para estimular la generación de ideas.
Generación sin filtro. Fomenta la mayor cantidad posible de ideas, promoviendo que las personas participantes combinen o mejoren las sugerencias de otras.
Recopilación. Dentro del grupo, una persona voluntaria o seleccionada, tomará la responsabilidad de registrar claramente cada idea, asegurando que ninguna se pierda. No es necesario que sea la única que toma nota visual o escrita, pero si que se encargue de compilar los resultados.
Foco. Ayuda a que el grupo escuche activamente cada aporte, sin desviarse del tema.
Limita el tiempo. Esto ayuda a mantener la energía y la concentración, ya que el proceso puede ser agotador.
Establece un seguimiento. Utiliza preguntas para detallar, precisar y provocar nuevas ideas a partir de la lista generada.
Clasifica y evalúa. Finalmente, organiza las ideas para seleccionar las más viables.

Alternativas

Brainwriting: En lugar de hablar en voz alta, los participantes escriben sus ideas en silencio y las intercambian para que otros las desarrollen. Ideal para grupos donde hay personas más introvertidas.
Tormenta de ideas inversa: En lugar de buscar soluciones, el grupo se enfoca en pensar todas las formas posibles de causar el problema. Esto ayuda a identificar riesgos y encontrar soluciones indirectas.
Carrusel de ideas: Se colocan varias estaciones con diferentes preguntas o temas, y los equipos rotan para aportar ideas a cada una, fomentando la diversidad de perspectivas.

El Diamante de Toma de Decisiones Participativa

2026-03-16T15:23:00.008-03:00

En el libro "Facilitator's Guide to Participatory Decision-Making", Sam Kaner propone, a través de una serie de alternativas y exploraciones, un modelo para entender el flujo de una actividad de facilitación, que usualmente llamamos el "Diamante de Kaner", por la forma del diagrama que lo ilustra:

La parte fundamental de este modelo, que podemos tener en cuenta para reflexionar sobre nuestros desafíos de facilitación es la división en tres etapas, que podemos mapear eventualmente en tres actividades separadas (o como veremos más adelante, en actividades que fusionan las tres).

En la Zona de Divergencia facilitaremos la inclusión de la mayor cantidad posible de alternativas al problema o desafío que se discute. La idea es evitar filtros y lograr abundancia de opciones.

En la Zona de la Queja buscamos convivir un rato con el caos creativo antes de pasar a "decidir". Esto incluye entender mejor el problema a través de las soluciones planteadas, discutir condiciones adicionales, eventualmente entender qué distintas estrategias o factores apoyan diferentes tipos de alternativas, o comprender las diferentes perspectivas que surgieron en la etapa anterior.

En la Zona de Convergencia, finalmente buscaremos que el grupo seleccione la o las alternativas mas indicadas según la inteligencia colectiva del grupo.

En la tabla siguiente dejo algunos ejemplos de actividades que pueden ser utilizadas en cada una de las zonas del diamante:

Divergencia: Brainstorming - SCAMPER - BotStorming - Reality Switch

Queja: Pros y Contras - Fishbowl - World Cafe - Matriz FODA

Convergencia: Consenso - Dot Voting - Backlog - Experimentos

Facilitación: Experimentos

2026-02-23T13:58:00.092-03:00

Si luego de analizar alternativas de solución a un desafío se llega a una situación en que:

Hay dos o tres alternativas muy interesantes
No hay una claramente superior a priori
Tenemos tiempo para tomar la decisión
Queremos validar las hipótesis detrás de cada una

...entonces tal vez conviene realizar una serie de experimentos cortos que brinden más información sobre cada una.

La decisión final quedará diferida hasta tener el resultado de esos experimentos (hablamos de plazos usualmente muy cortos, de pocos días).

Diseño de Experimentos

Para evitar sesgos cognitivos y aclarar las expectativas del grupo, conviene tener en cuenta al menos los siguientes atributos mínimos que definen un experimento:

Hipótesis: Lo más importante es acordar qué queremos comprobar
Acción/Prueba: Realizamos una acción en condiciones seguras y observando activamente, para tratar de verificar la hipótesis
Métrica: Definimos en conjunto qué cosas tenemos que medir para saber si la hipótesis se comprueba.
Muestra/Repeticiones: Puede ser necesario ejecutar la acción en diversos contextos, o más de una vez, para que el resultado sea más significativo. Lo ideal es identificar la menor cantidad necesaria de acciones, para no prolongar demasiado el experimento.
Criterio: Es importante acordar los valores finales esperados (exactos o porcentuales) antes de realizar las acciones, para evitar sesgos de auto-confirmación.

Facilitación: Backlog

2026-02-20T13:46:00.004-03:00

Como Scrum nos ha enseñado, a veces la mejor decisión es avanzar un poco, inspeccionar y adaptar.

Para eso, a veces podemos coverger desde el total de alternativas (generadas en la zona de convergencia, y analizadas en la zona de la queja) hacia un Backlog de Alternativas (o de Experimentos).

En ese caso utilizamos las mismas prácticas que al armar un Product Backlog, priorizando y refinando los próximos pasos a dar, de manera de validar que vamos en el sentido correcto, o dándonos la posibilidad de pivotear.

Recordemos algunas de las características fundamentales de un Backlog en Scrum:

Los ítems están ordenados en el orden de su expectativa de valor en el momento
Permite discutir y renegociar ese orden
Permite un plan iterativo en el que trabajamos con N ítems (tomados desde arriba)
Siempre podemos "fetear" un ítem para distribuir las partes en otro orden, facilitando el avanzar con la parte fundamental más valiosa, difiriendo otras hasta aprender
Reevaluamos los ítems y su orden restante, luego de trabajar en los anteriores, aplicando el aprendizaje de cada iteración previa.

Más sobre el Product Backlog.

Facilitación: Dot Voting

2026-02-18T13:24:00.040-03:00

Durante la facilitación de decisiones, después de varias evaluaciones, queda la labor de converger hacia una opción entre las demás.

Una técnica sencilla y muy popular es la votación por puntos.

Puede ser sobre una lista pre-armada o sobre una serie de elementos que recién se acaban de generar como notas en un tablero.

Pasos

Desambiguar: Es importante que antes de votar nos aseguremos que no hay ítems repetidos (en ese caso podemos dejar uno solo) o que queden diferentes ítems muy disímiles (por ej: frutas, manzanas, naranjas, peras. Conviene sacar “frutas”, para que el voto no sea ambiguo).
Votar: La actividad de votación consiste en que cada participante tenga un número acotado de votos (usualmente 3 o 5, dependiendo de la cantidad de ítems) y pueden colocarlos en cualquiera de los ítems, distribuyendo como quieran.

Pueden votar:

Un punto en cada ítem elegido
Varios puntos en ítems diferentes
Todos sus puntos en uno solo

Los “puntos” pueden ser stickers/pegatinas, tildes con marcador, o cualquier elemento en un tablero virtual (hay varias herramientas que tienen la funcionalidad de “votar” ítems ya incorporada).

Recuento: Al finalizar se hace el recuento y se determina el ítem más votado. Si hay empate en el primer puesto, se pueden buscar alternativas de resolución, o realizar otra ronda con dos o tres puntos, pero sólo entre los ítems que quedaron empatados.

Facilitación: Consenso rápido

2026-02-17T18:34:00.000-03:00

A veces, podemos evitar votar o hacer una actividad completa si primero, como facilitadores, hacemos una verificación rápida sobre la posibilidad de llegar a un consenso.

Algunas preguntas a hacerse al observar al grupo:

¿Parece haber una opción claramente preferida por los asistentes?
¿Durante el análisis de las opciones hay una que tiene MUCHAS ventajas sobre las demás?
¿Fue notorio al trabajar en alguna de las opciones que emocionalmente una de ellas despierta más entusiasmo?

En esos casos, es mejor sondear rápidamente sobre si hay una opción favorita. Para evitar "apagar" otras alternativas, podemos sondear rápidamente si alguien tiene la más leve duda, resaltando que estamos a tiempo de hacer una votación más detallada. Podemos sostener un silencio de dos o tres minutos, y si no aparece oposición, convergemos de inmediato.

De lo contrario, conviene volver a plantear otro mecanismo de votación o priorización, dentro del tiempo que todavía teníamos destinado en el plan.

Facilitación: FODA

2026-02-16T18:04:00.001-03:00

La Matriz FODA (también conocida como DAFO o SWOT) es una herramienta de análisis estratégico que evalúa la situación de un proyecto u organización. Sus orígenes se remontan a la década de 1960 en el Stanford Research Institute, popularizándose posteriormente como un marco para la planificación.

Se compone de cuatro elementos: Fortalezas (internas positivas), Debilidades (internas negativas), Oportunidades (externas positivas) y Amenazas (externas negativas).

Pasos

Alternativas: La actividad se puede realizar con diferentes grupos evaluando las alternativas surgidas en una actividad previa de divergencia.
Tableros: Marcos con cuatro cuadrantes (en papel o digital) donde las personas participantes agregarán notas de papel con factores a considerar en cada una de los cuatro perspectivas.
Análisis:
Las alternativas a analizar (surgidas durante la actividad de divergencia) se reparten en distintos grupos, y cada uno trabaja en un tablero, completando los cuatro cuadrantes.

Análisis Externo: Oportunidades y Amenazas (mercado, competencia, tecnología)
Análisis Interno: Fortalezas y Debilidades internas (recursos, capacidades, marca)

Alternativas

Análisis PESTEL: Para profundizar en el entorno externo (Político, Económico, Social, etc.).

5 Fuerzas de Porter: Para evaluar amenazas competitivas específicas.

Matriz de Eisenhower: Si el grupo se enfoca en la priorización de los factores identificados.

Facilitación: World Café

2026-02-10T20:11:00.002-03:00

Este formato de diálogo grupal fue creado en 1995 por Juanita Brown y David Isaacs en San Francisco.

Sitio Oficial - Sitio en Español

Nació de manera espontánea cuando una reunión se vio interrumpida por la lluvia y los participantes se dispersaron en pequeñas mesas con manteles de papel, generando conversaciones informales que luego compartían al mezclarse entre grupos. Al notar la energía y profundidad de esos intercambios, Brown e Isaacs desarrollaron la estructura que hoy se utiliza globalmente en organizaciones, comunidades y empresas.

Genera inteligencia colectiva a través del diálogo en pequeños grupos, replicando la atmósfera relajada de un café. Es ideal para grupos de entre 12 a 50 personas, donde los participantes se sientan en mesas de 4 a 6 (dependiendo del espacio, siempre prefiriendo grupos más pequeños) y conversan en rondas sucesivas sobre preguntas que realmente importan al grupo . Al final de cada ronda, los comensales cambian de mesa, llevando consigo las ideas para conectarlas con las de otros, creando una red densa de conversaciones que se profundizan progresivamente .

Pasos

Espacio amable: Mesas con manteles de papel, marcadores de colores, flores y, si es posible, café o té. El ambiente debe invitar a la conversación relajada y creativa.
Preguntas que importan: Formula preguntas abiertas y genuinas, relevantes para los participantes. La primera ronda suele ser amplia y exploratoria; las siguientes pueden enfocarse en acciones o profundizar en patrones detectados.
Primera ronda de conversación (20-25 min): En grupos pequeños por mesa, las personas dialogan sobre la primera pregunta mientras dibujan o escriben sus ideas en el mantel.
Cambio de mesa (5 min): Una persona por mesa se queda como anfitriona para recibir al nuevo grupo y resumir lo conversado. El resto se mezcla y se sienta en otras mesas.
Repite las rondas (20 min cada una): En la segunda ronda, se introduce una nueva pregunta que profundice o complemente la anterior. Los participantes conectan las ideas escuchadas previamente con las nuevas conversaciones.
Cosecha: Tras las rondas, se realiza una puesta en común donde los grupos comparten los patrones, insights o ideas emergentes. Puede hacerse creando una "galería" donde se exhiben los manteles o con una ronda de síntesis grupal.

Alternativas

Knowledge Café: Prescinde de mesas y estructuras formales. No hay preguntas predefinidas ni temas asignados. La gente se mueve e integra a cualquier conversación, alentando que no mantengan grupos demasiado estables.

Carrousel: Los grupos rotan de manera conjunta. En cada estación, el grupo encuentra las ideas o propuestas generadas por el grupo anterior y las mejora, añadiendo nuevos aportes, combinando perspectivas o refinando lo ya trabajado. Tras varias rondas de rotación, las ideas han pasado por múltiples ciclos de retroalimentación y enriquecimiento progresivo, permitiendo que el consenso emerja de manera gradual sin necesidad de debates formales o votaciones estructuradas.

Facilitación: Fishbowl

2026-02-05T20:07:00.000-03:00

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

2026-02-02T19:28:00.000-03:00

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

2024-06-24T15:46:00.003-03:00

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

2023-03-21T16:13:00.007-03:00

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

2020-07-15T20:11:00.003-03:00

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.

Scrum: Incremento de Producto

2020-03-06T14:05:00.001-03:00

En el Manifiesto por el Desarrollo Ágil de Software, hoy más conocido como el Manifiesto Ágil, hay 4 valores y 12 principios, uno de los cuales dice:

El software funcionando es la medida principal de progreso.

En Scrum, ese principio está representado por el Product Increment. Es importante notar que Scrum ya no habla de software, pero la definición del incremento en la Scrum Guide dice (mi traducción):

El incremento es la suma de todos los ítems del Product Backlog completados durante un Sprint y el valor de los incrementos de todos los previos. Al final del Sprint, el nuevo incremento debe estar "Terminado", lo que significa que debe estar en condición de ser utilizado y cumplir con la definición de "Terminado" del Equipo Scrum.

Podríamos decir que en Scrum, la principal medida de progreso es el Incremento de Producto funcionando.

Este incremento es entonces, una versión actualizada y funcionando del producto que se entrega al final del Sprint (agregando valor sobre los incrementos previos).

El Product Owner es quien tiene la responsabilidad de decidir si ese incremento se libera al mercado (se pasa a producción, se pone en marcha o su equivalente de acuerdo al tipo de producto), más allá de que sea usable.

Que el Incremento deba estar "terminado" significa que debe poder ser liberado sin trabajo adicional del Scrum Team.

Atención

La Guía Scrum no especifica qué sucede con esfuerzo adicional fuera del equipo para entregar el producto a su público objetivo. Por ejemplo, en muchas organizaciones el equipo entrega un producto de software terminado, pero para pasarlo a producción el esfuerzo de otras áreas puede ser enorme. La comunidad ágil alienta a trabajar en reducir esa brecha, por ejemplo, a través de prácticas de DevOps (que NO es un rol ni un área, sino un estilo de colaboración entre desarrollo y operaciones).

La Definición de Terminado

La DoD (del original en inglés, Definition of Done) es creada por el Scrum Team com una manera de evaluar si su trabajo en un ítem del Product Backlog ó en el Incremento está completo.

El objetivo de esta definición es brindar transparencia sobre el nivel de calidad que se considera suficiente para entregar el Incremento de Producto.

La definición es dinámica, y a través de los Sprints será inspeccionada y adaptada, en colaboración entre el Scrum Team y los Stakeholders.

Es importante que el Development Team tenga esta definición en cuenta a la hora de determinar cuánto comprometer durante la Sprint Planning. Una buena Definición de Terminado balancea el nivel de calidad esperado con el esfuerzo requerido.

Es común que la definición varíe mucho entre diferentes equipos, ya que depende mucho del tipo de producto, el contexto y la madurez en diferentes aspectos.

Cuando múltiples equipos trabajan sobre el mismo producto, usualmente colaboran para tener una Definición de Terminado mínima, compartida por todos, sobre la que cada equipo puede agregar sus propias condiciones.

Tips

En mi experiencia, es preferible comenzar con una definición humilde pero alcanzable, y trabajar con el Scrum Team en seleccionar qué prácticas pueden elevar el nivel de calidad del producto, priorizándolas. Es usual que esas prácticas tengan una curva de aprendizaje, que hace que el equipo deba inicialmente invertir más esfuerzo en cada ítem.

La buena noticia es que las prácticas de calidad, una vez que tienen impacto, ahorran esfuerzo en la medida en que el producto se vuelve más estable y el equipo las incorpora como propias. En el momento en que el equipo ya está acostumbrado a esa nueva práctica, puede agregar la condición correspondiente como parte de la Definición de Terminado, y comenzar con la adopción de la próxima práctica de calidad que sea más prioritaria.

Para ayudar a pensar en posibles ítems de la Definición de Terminado de un equipo, en Kleer creamos una guía ágil y las DoD Cards, con ejemplos y sugerencias.

Scrum: Sprint Backlog

2020-03-05T17:46:00.002-03:00

El Sprint Backlog es el subconjunto de ítems que un equipo "toma" del Product Backlog como compromiso de trabajo para un Sprint, con algunos agregados.

Esta selección de ítems se realiza durante la Sprint Planning, y los agregados que el equipo hace representan la estrategia para cumplir con esos ítems y alcanzar el Objetivo del Sprint y entregar el Incremento de Producto.

La Guía de Scrum no entra en detalle específico de esa estrategia, pero en muchos casos se trata de una desagregación de tareas para cada ítem, de acuerdo a diversas perspectivas como componentes, especialidades, áreas de trabajo, u otras que el equipo determine.

Es recomendable tener en cuenta que aunque cada ítem se descomponga en tareas, el equipo tiene como objetivo principal lograr ítems completos, que ayuden a alcanzar el objetivo, y tiene que evitar caer en la trampa de dedicarse a completar tareas en cualquier orden, según la especialidad de cada uno, sino en colaborar activamente para terminar ítems, respetando el orden de prioridad original.

El Sprint Backlog usualmente se hace visible a través del uso de un tablero, físico o electrónico, y es importante que esté disponible para todos los interesados y permita ver claramente el estado de cada ítem, de manera transparente.

También es recomendable que junto a los ítems del Sprint Backlog, el tablero mantenga altamente visible al menos un elemento de mejora decidido en la última retrospectiva.

Es común que el equipo modifique y complete detalles del Sprint Backlog a medida que avanza en el Sprint, posiblemente como resultado de la Daily Scrum. Todo ajuste tiene por objetivo mejorar las posibilidades de alcanzar el Objetivo del Sprint.

El Development Team es el único que puede alterar el Sprint Backlog, agregando, actualizando o removiendo detalles. El resto del Scrum Team y los Stakeholders sólo tienen acceso a éste para ver el estado de avance, sobre el que pueden pedir más detalles al equipo. En mi opinión no es bueno tomar el estado de actualización del Sprint Backlog como única fuente de información, sobre todo en caso de notar algo fuera de ciertas expectativas. En un ambiente colaborativo como el de Scrum, la comunicación cara a cara siempre brinda detalles que nos dan una visión más clara de las cosas.

Scrum: Product Backlog

2020-03-04T17:53:00.002-03:00

Para poder desarrollar un producto con Scrum, un equipo necesita tener un Product Backlog.

Se trata de una lista priorizada de todo lo que el producto debe tener, y representa el entendimiento actual del alcance del producto. Como el Product Backlog es dinámico, a medida que se descubran nuevas características, su contenido irá evolucionando.

Esa evolución se da a través de los Sprints, a medida que:

Se pasan ítems al Sprint Backlog, durante la Planning.
Se agregan nuevos ítems que sean valiosos para el producto
Se eliminen ítems cuyo valor ya no es relevante
Se descompongan ítems grandes en otros más pequeños
Se cambian las prioridades de los ítems, al reconsiderar su valor actual

Una idea central es que el Product Backlog es la única fuente de trabajo relativa al producto para el equipo. Sus ítems contienen todas las características, funcionalidades, mejoras, correcciones o extensiones que el producto necesite, y por lo tanto, todas se priorizan en conjunto, para ser desarrolladas por el mismo equipo ó equipos de producto.

Cuando un producto es muy grande, el esfuerzo puede distribuirse entre más de un equipo, con un único Product Backlog (y un único Product Owner), que representa la prioridad actual para el producto completo, en vez de prioridades parciales por componentes o áreas.

El Product Owner es el responsable por su contenido, visibilidad y priorización.

El Product Backlog sirve para responder a la pregunta "¿qué es lo próximo a desarrollar?" y aporta una restricción sana a la situación de que los Stakeholders siempre tendrán deseos aparentemente ilimitados para el producto, pero las organizaciones tiene recursos acotados.

Al hacer las prioridades transparentes para todos los involucrados, se habilita la discusión de cómo se distribuye el esfuerzo dentro de la capacidad disponible, siempre con la restricción adicional de la duración del Sprint.

Refinamiento del Product Backlog

Los ítems del Product Backlog (o PBI: Product Backlog Items) están ordenados entonces por su importancia en cada momento, y los más importantes suelen estar "refinados", es decir que ya están:

Con su valor establecido (y ordenados en consecuencia)
Divididos en los ítems más pequeño posibles
Estimados (el equipo debe saber al menos que puede desarrollar varios en un Sprint)
Detallados (suficiente como para que nada se bloquee en la Planning)

Los ítems que tienen menor prioridad (aún lejos de ser considerados en un Sprint o dos) pueden tener menos nivel de detalle, y aún no estar divididos en partes más pequeñas. Casualmente en Scrum diferimos estratégicamente esa tarea, para:

Aprovechar todo el aprendizaje previo al momento de analizar un ítem, sobre todo el ver el incremento más reciente del producto, lo que influye muchísimo sobre próximas decisiones.
Evitar analizar ítems que pueden variar (o desaparecer)

La actividad de agregar estos detalles al Product Backlog no es un "evento" sino una tarea permanente del Product Owner, llamada Product Backlog Refinement, que realiza colaborativamente junto a los Stakeholders y resto del Scrum Team.

La recomendación de involucramiento del Development Team en esta actividad es que no exceda el 10% del tiempo disponible del Sprint, pero eso es usualmente bastante tiempo.

Más allá de esa recomendación no hay ningún proceso ni límite de tiempo establecido, y cada equipo Scrum decide y mejora continuamente cómo realiza el refinamiento.

Es importante entender que los ítems que se refinan durante un Sprint no son los que ya están en el Sprint Backlog (y por ende, durante la Planning, se fueron del Product Backlog), sino los que siguen en prioridad, y pueden ser incluidos en el próximo Sprint (y un poco más, ya que no se puede predecir con exactitud lo que sucederá en la siguiente Planning).

También es importante, en mi opinión, que las actividades de Refinamiento no se conviertan en una Planning anticipada. Si se baja a demasiado detalle, sobre todo con el Development Team, estaríamos causando una sobrecarga cognitiva, ya que están trabajando en una serie de ítems (el Sprint Backlog actual) y no queremos distraerlos con detalles que pueden quedar para la Planning, cuando ya están liberados y listos para comenzar otro ciclo.

La estructura de Scrum

2020-02-26T18:53:00.000-03:00

Siguiendo con la premisa de que Scrum es "fácil de entender, pero difícil de dominar", avancemos con la parte fácil. 😁

Scrum está compuesto, además de sus pilares y valores, por una serie de artefactos, eventos y roles.

AVISO
Este artículo es una guía inicial, que se irá completando con links a detalles más completos (en artículos separados) a lo largo de las próximas semanas.

Artefactos -> Transparencia

Los llamados "artefactos" de Scrum son elementos mínimos para lograr alto grado de transparencia respecto al planes, trabajo pendiente y resultados obtenidos.

Product Backlog

El Backlog (o Pila) de Producto es una lista ordenada de todo lo que el producto pueda necesitar. Es una lista en constante evolución, dinámica, y es la única fuente de trabajo para el equipo.

El orden en que están los ítems del Product Backlog transparentan la visión y estrategia de producto que clientes, gente de negocio y equipo comparten, poniendo énfasis en que lo que está en los primeros lugares es lo que queremos que el producto tenga en el más corto plazo.

Sprint Backlog

El Backlog (o Pila) del Sprint es un subconjunto del Product Backlog, seleccionado por el equipo para trabajar en un Sprint (o iteración), al que se agrega un plan de cómo convertir esos ítems en un incremento de producto cumpliendo el objetivo del Sprint.

El Sprint Backlog transparenta el trabajo del equipo durante el sprint, incluyendo el objetivo general y otros indicadores que sirvan al equipo y al resto de la organización.

Product Increment

El Incremento de Producto es la suma de todos los ítems del Product Backlog terminados durante el Sprint, agregado al valor obtenido en todos los Sprints anteriores.

Este Incremento transparenta de manera radical el estado del producto. Es una versión del producto utilizable y completa, independientemente de que se decida entregarlo o no a la audiencia final.

Para asegurar esa usabilidad, el Incremento debe cumplir con la Definition of Done (definición de terminado) que el equipo tiene acordada.

Eventos -> Inspección y Adaptación

Los eventos de Scrum brindan la estructura temporal mínima, evitan reuniones adicionales, y tratan de minimizar el desperdicio de tiempo y esfuerzo.

Sprint

El Sprint (iteración) es el corazón de Scrum. Es un contenedor de todos los demás eventos más el trabajo regular de desarrollo. Marca el pulso de trabajo, siendo su duración inalterable y estable a lo largo del ciclo de vida del producto.

Cada Sprint comienza con una planificación de su Objetivo y su Sprint Backlog, trabajo de desarrollo de producto, que se sincroniza diariamente, un Incremento de Producto que es revisado sobre el final, y un espacio de reflexión para la mejora continua.

Sprint Planning

Al inicio de cada Sprint, el equipo se reúne para definir el Objetivo del Sprint, y seleccionar los ítems del Product Backlog en los que trabajarán para cumplirlo. Esos ítems, junto con información adicional de cómo desarrollarlos, se convierten en el Product Backlog.

En la Planning el equipo inspecciona las expectativas de corto plazo sobre el producto y adapta su estrategia para lograr un resultado concreto.

Daily Scrum

Todos los días a la misma hora y el mismo lugar, el equipo se reúne durante un máximo de 15 minutos para inspeccionar cómo avanza hacia el objetivo del Sprint y adaptar sus planes para alcanzarlo.

El resto del día, a excepción de los eventos de inicio y fin del Sprint, el equipo se dedica al desarrollo del producto mismo.

Sprint Review

Sobre el final del Sprint, el equipo colabora con clientes, gente de negocios u otros interesados para inspeccionar el Product Increment, de manera de poder adaptar, a través de actualizaciones al Product Backlog y un entendimiento común, los planes hacia adelante.

Sprint Retrospective

La "Retro" es una oportunidad para que el equipo se auto-inspeccione, y adapte su manera de trabajar, mejorando de manera continua.

Es el momento principal en que el equipo decide cómo le conviene hacer todo lo que Scrum no dice, como temas de relacionamiento, técnicos, de comunicación, organizacionales, y otros.

Roles

Un equipo Scrum tiene solamente tres roles internos: el Development Team (o equipo de desarrollo), formado por múltiples profesionales, y otros dos que son individuales, el Product Owner y el Scrum Master.

La suma de las personas cubriendo estos tres roles en un equipo es lo que se llama Scrum Team (o equipo Scrum).

Todas las personas interesadas en el producto que pueden interactuar con el Scrum Team pero no forman parte de él son llamados Stakeholders, o involucrados. Entre ellos puede haber clientes, personas de negocios, personas de otras áreas de la organización que tienen influencia sobre el producto, como marketing, legales, tecnología, atención a clientes, y también personas externas a la organización como consultores, auditores, analistas de mercado, y muchos otros.

Development Team

Es un grupo multi-disciplinario de profesionales que se encargan de entregar un incremento de producto utilizable al final de cada Sprint.

Product Owner

Es la responsable de maximizar el valor del producto que entrega el Development Team. La manera en que lo hace es muy diferente en cada equipo, pero se centra alrededor de la administración del Product Backlog.

Scrum Master

Es la responsable de promover y dar soporte a Scrum, ayudando a que todos comprendan y usen apropiadamente sus valores, prácticas y reglas.

Pilares y Valores de Scrum

2020-02-25T14:53:00.001-03:00

Una contradicción frecuente en personas y organizaciones interesadas en adoptar Scrum es que no se resignan a dejar de preguntar cosas como: "¿Cuándo va a estar lista exactamente ésta característica del producto tal cuál yo pedí?"

La pregunta no está mal en sí misma, pero corresponde a lo que se conoce como "Control de procesos definidos", donde tenemos un plan establecido, y el alcance del proyecto/producto está completamente cerrado. Este tipo de procesos sigue siendo útil en temas como la ingeniería civil, o la industria de la construcción, por milenios, aunque como sabemos, las predicciones en este modelo muchas vez no son correctas.

Procesos de Control Empírico

Scrum no sirve como modelo predictivo, porque se encuadra dentro del modelo empírico. Este modelo se aplica cuando aceptamos que el nivel de incertidumbre de nuestro desafío es alto.

No por casualidad, Scrum tiene mucho éxito en lo que llamamos contextos VICA:

Volatilidad
Incertidumbre
Complejidad
Ambigüedad

De este estilo de control de procesos Scrum hereda sus tres pilares fundamentales.

Pilares de Scrum

Transparencia, Inspección y Adaptación

Podemos recorrer estos tres principios pensando en la pregunta original. Si el problema es complejo y la solución es incierta, ¿cómo podemos entonces saber cómo vamos?

La transparencia en Scrum es de doble vía: los clientes o el "negocio" deben brindar información concreta al equipo sobre sus hipótesis, objetivos y dependencias, y el equipo debe dar transparencia de sus planes, decisiones y sobre todo, resultados.

En base a esos datos, y en iteraciones cortas, el equipo mostrará resultados concretos (no planes, diseños ni porcentajes, sino un producto funcional) que inspeccionarán junto a los clientes o "negocio", entendiendo:

Decisiones acertadas o no
Hipótesis de negocio comprobadas o no
Calidad del producto
Estado actual frente a un contexto volátil
Comprensión correcta entre todos, en un entorno ambiguo

Basados en este aprendizaje, el equipo y sus clientes adaptan su plan hacia adelante, poniendo en juego una nueva serie de premisas, objetivos de corto plazo y estrategias.

Todo esto se repite en ciclos permanentes, ya que los procesos empíricos se basan casualmente en la iteración continua.

Pero Scrum agrega a estos pilares una serie de principios que se encuentran detrás de cada uno de los roles, eventos y artefactos, junto con los pilares.

Valores de Scrum

Compromiso, Coraje, Foco, Apertura, Respeto

Estos valores, que muchas veces se ignoran en adopciones de Scrum, tomando solamente la parte mecánica (los roles, eventos y artefactos) son los que revelan la intención detrás del marco de trabajo, y permiten entender mejor el porqué de cada pieza.

Veamos un poco el origen de estas palabras (en su versión inglesa original) y porqué tienen tanta importancia en Scrum:

Compromiso (commitment)

Viene de "confiar a alguien, delegar autoridad", y refiere a unirse por un objetivo común.

En Scrum, los miembros del equipo se comprometen de manera personal, para cumplir con un objetivo colectivo. Dentro del equipo cada uno es responsable y rinde cuentas a los demás, pero hacia fuera comparten una responsabilidad y rinden cuentas como grupo.

La importancia de este principio es que no se puede afectar la autonomía del equipo como tal, tratando de "gestionar" a miembros individuales, ni se puede reducir ese compromiso haciendo que los miembros tengan responsabilidades fuera de su equipo.

Coraje (courage)

Originalmente, "desde el corazón", se entiende como el tomar acción en base a nuestras creencias o principios.

En Scrum, se espera que el equipo mantenga los principios de Scrum y sus acuerdos, sobre todo cuando no sea fácil hacerlo. Tiene que ver con "hacer lo correcto, de la manera correcta", y refiere a mantener el objetivo común y la calidad técnica, pero implica un alto nivel de autonomía.

Un equipo Scrum no puede sentirse limitado por decisiones externas, y constantemente cuestionará normas o políticas que no considere positivas para alcanzar sus resultados de manera sostenible.

Foco (focus)

Proviene de "fuego", y tiene que ver con reunirse alrededor de la fuente de calor. Por eso lo usamos para algo que nos mantiene "mirando hacia ese lado".

Scrum es una manera de mantener al equipo permanentemente enfocado en el trabajo de la iteración actual (sin preocuparse por detalles de lo que vendrá, más allá de la visión de conjunto) y de sus objetivos como equipo, que surgen siempre de lo que es importante "ahora" para el producto.

Apertura (openess)

Algo abierto es algo expuesto y evidente.

En Scrum (dado el pilar de transparencia) se expone abiertamente tanto el plan, el trabajo en marcha, los resultados, y sobre todo, los desafíos (del equipo, de la organización, del producto, del mercado, de los clientes, y otros).

La apertura en cuanto a todo, incluyendo feedback abierto sobre todos los temas, permiten efectuar todo el tiempo el proceso de inspección y adaptación.

Respecto (respect)

Refiere originalmente a "ver" o "volver a mirar", y significa apreciar sinceramente las características únicas de otras personas.

En Scrum se propicia el respeto cruzado, de los clientes hacia la capacidad y autonomía del equipo, del equipo al entendimiento del negocio y sus desafíos de los clientes, pero también entre cada miembro del equipo, y por sus roles y responsabilidades.

Pero ese respeto implica que todo está abierto a cuestionamientos, de manera amable, con el objetivo de que las partes se entiendan lo mejor posible, elevando siempre la transparencia.

¿Y cuál es la respuesta?

Antes de comprender la estructura de Scrum, entonces, es importante entender que podemos preguntar o no.

Esto no quiere decir que no podamos tener fechas límites, o limitaciones de presupuesto. Lo que no trata de hacer Scrum es predecir nada.

Scrum no es un modelo predictivo, es un modelo adaptativo.

Las preguntas constantes en Scrum serán entonces, inspeccionando el producto frecuentemente:

¿El producto agrega valor?
¿Estamos más cerca de resolver el problema?
¿Vale la pena seguir adelante, o hay otro problema más valioso por resolver?

Y así, mediante continua inspección y adaptación, en muchos casos podremos tener resultados mejores a los que tenemos tratando de cumplir con predicciones que ya no son relevantes.

¿Qué es Scrum y para qué se usa?

2020-02-24T16:08:00.001-03:00

Aquí comienza una serie de artículos en que intentaré describir el marco de trabajo Scrum, cubriendo temas que en su momento no quedaron incluidos en el libro "Proyectos Ágiles con Scrum" que escribimos con mi amigo Martín Alaimo. Tal vez al terminar la serie tenga el material para una nueva edición, o para un libro nuevo, pero eso ya lo veremos.

Sitio de la Guía de Scrum

¿Qué es Scrum?

Según la Scrum Guide (la guía oficial que mantienen Ken Schwaber y Jeff Sutherland, los desarrolladores originales) Scrum es (mi traducción):

Un marco de trabajo en el que las personas abordan problemas adaptativos complejos, mientras entregan productos del mayor valor posible de manera productiva y creativa.

Me gusta esa definición que fue evolucionando a lo largo del tiempo, pero voy a tratar de analizarla por partes, para evitar algunas confusiones comunes.

Un marco de trabajo...

Como dicen los autores, Scrum no es un proceso, ni una técnica, ni un método definido. Es un marco intencionalmente incompleto.

Scrum brinda apenas un conjunto mínimo de Roles, Eventos, Artefactos y las reglas que los enlazan, sin entrar en detalles profundos sobre los mismos. Scrum no viene "listo para usar", y no es algo que un equipo (mucho menos varios equipos) pueden aprender y dominar en un par de semanas.

Scrum requiere paciencia para adaptarlo constantemente, y no hay una situación en la que alcanzamos el "máximo nivel posible". Como con casi todo sistema de mejora continua, si creemos que ya alcanzamos el máximo rendimiento, seguramente estamos en graves problemas.

...en el que las personas...

Esto es fundamental, y es fuente de muchísimas confusiones. Scrum no es una herramienta de management, al menos en el sentido tradicional. No es un marco para dirigir y controlar "recursos". Es un marco en el que las personas, individualmente y como equipo, se auto-organizan para lograr un objetivo común.

...abordan problemas adaptativos complejos, mientras entregan productos...

Scrum no es útil para problemas bien definidos o de baja complejidad. Por ejemplo, es probable que no aporte valor en un proceso de manufactura o prestación de servicios en serie, una vez que estos ya fueron definidos. Incluso si en ambos casos se puede aplicar mejorar continua, hay marcos mas útiles.

Mas allá de que Scrum es utilizado cada vez en más industrias y áreas, en líneas generales aplica al desarrollo de productos (o servicios) a lo largo de todo su ciclo de vida.

Pero tampoco es una definición exacta. Por la dificultad de determinar qué es un productoy que no. Y también porque nuestro contexto es cada vez más complejo.

...del mayor valor posible de manera productiva y creativa

El gran aporte de Scrum (al igual que otros marcos ágiles) es la entrega continua y frecuente de un producto para resolver ese problema adaptativo complejo.

La productividad de Scrum está basada en que el equipo de trabajo usa su creatividad y auto-organización para entregar un producto que se puede observar en períodos muy cortos, sobre el que se puede reflexionar y ajustar para seguir desarrollándolo.

Es común ver adopciones de Scrum que no ponen énfasis en entregar producto de forma frecuente, o sólo lo hacen a nivel interno, sin ponerlo en producción, ó lanzarlo al mercado, ni siquiera para una audiencia reducida que luego vaya en aumento.

Otras características

Una a frase adicional que destaca otras características de Scrum es que "es un marco de trabajo liviano, simple de comprender, pero difícil de dominar".

Es liviano porque no requiere demasiada supervisión. Por lo contrario, lo que suele costar en organizaciones con alto nivel de formalidad, es que requiere menos supervisión y más delegación de responsabilidades.

Es tan simple de comprender que los cursos iniciales son de dos días como máximo, y la Guía mencionada tiene menos de 20 páginas, que al quitar portada, índice, agradecimientos y demás agregados llegan apenas a una docena.

Pero es difícil de dominar porque requiere práctica y adaptación al problema, el producto, el equipo, la organización y muchas otras variables que hacen al contexto en que será utilizado. Al no haber una receta, depende del equipo mismo. La buena noticia es que Scrum sirve casualmente para eso, para ayudar a que un equipo madure de manera continua mientras entrega incrementalmente un producto.

Hacia adelante

Esta definición es de muy alto nivel, y lo que queda para entender Scrum, a través del resto de esta serie, son sus elementos:

(nota: en la serie utilizaré para la mayoría de los elementos los nombres originales en inglés, ya que las traducciones pueden ser ambiguas, y son términos sencillos y muy utilizados)

Pilares: Transparencia, Inspección y Adaptación
Valores: Compromiso, Coraje, Foco, Apertura y Respeto
Estructura general

Artefactos: Product Backlog, Sprint Backlog, Product Increment
Eventos: Sprint, Planning, Daily Scrum, Review, Retrospective
Roles: Development Team, Product Owner, Scrum Master (y stakeholders)

y las pocas reglas que los vinculan:

3 elementos para una Arquitectura más Ágil

2018-09-14T15:36:00.001-03:00

Esta semana me pidieron en un cliente si podía compartir algunas definiciones o lineamientos sobre agilidad en Arquitectura de Software, para trabajar en una reunión interna.

Como otras veces, después de pensar la respuesta y escribir un poco, les pedí permiso para compartir las ideas en este blog, y aquí van los tres elementos a los que llegué, a través de algunas preguntas de ellos:

Arquitectura incremental

Igual que con el diseño funcional, desconfiamos del "gran diseño preliminar", y tratamos de empezar con la arquitectura mínima necesaria para la funcionalidad que estamos encarando. Podemos hacer este ejercicio, idealmente, Sprint a Sprint, decidiendo sobre la arquitectura en cada planning.

IMPORTANTE: esto no implica que no iniciemos con algunos elementos mínimos de referencia, que nos son comunes (un lenguaje, un framework, una base de datos, etc). Es común que dentro de una organización tengamos algunos lineamientos (idealmente definidos de manera colaborativa). Lo que nos dejamos abierto es la posibilidad de cambiar algo más adelante, si nos damos cuenta que nos conviene.

Validación continua

Más allá de una visión general de guía, igual que con la funcionalidad, tratamos de dejar una prueba automatizada que nos ayuda a validar que logramos el efecto que queríamos al implementar cada pieza de arquitectura: por ejemplo, pruebas de performances, de extensibilidad, validaciones de nivel de acoplamiento o complejidad, etc. Esas pruebas se ejecutan de manera continua, al igual que las pruebas unitarias o de aceptación.

Esa validación permanente en el entorno de desarrollo/QA se extiende también a mediciones en el proceso automatizado de deployment, y al monitoreo de la solución en el ambiente productivo (monitoreo de servidor, clientes, dispositivos, plataforma, etc). Todo ese seguimiento es lo que nos permite entender si nuestra arquitectura realmente está soportando lo que necesitamos en este momento, y también comprobar si cualquier cambio tiene el efecto deseado o no. Ese nivel de feedback es lo que nos permite encarar cambios en la arquitectura sin entrar en pánico.

Demasiado importante para dejárselo a los Arquitectos

Como no diseñamos la arquitectura por completo en el inicio, tampoco se define desde un rol centralizado o mediante especialista en un silo. Aunque haya personas en el equipo con el título de Arquitecto, el tema se discute con todo el equipo y con los involucrados del negocio, y las decisiones se realizan de manera colaborativa, teniendo en cuenta todos los puntos de vista.

Las decisiones tampoco suelen ser finales, sino que se diseñan experimentos, con métricas asociadas y un objetivo a alcanzar, que se validado o no en la implementación.

Nuevamente, este no quita que exista un equipo de Arquitectura Corporativa o algo similar. La diferencia es que esos grupos se ocupan más de entender las restricciones generales necesarias para el negocio, la plataforma común, el ecosistema de diferentes aplicaciones (propias y de terceros), y actúa como un participante frecuente en las reuniones de planificación de los equipos, no para imponer definiciones, sino para tener feedback y colaborar en las definiciones de cada aplicación.

Finalmente, como para otras actividades, interese o tecnologías (testing, diseño, JS, bases de datos, temas de negocios) el intercambio y alineamiento de temas de arquitectura entre diferentes equipos se puede realizar mediante espacios de Comunidades de Práctica.

Continuando la discusión

Obviamente estas ideas están resumidas y tienen mucho más detrás. Si te interesa continuar este tema, algunas de las cosas en las que he trabajado a lo largo de los años son:

El paper “Software Architecture in the Agile Life Cycle” que publicamos en 2010 con mi amigo y colega de la vida Diego Fontdevila.
(Original en inglés, en el Architecture Journal; ó versión en español, actualizada en 2013)
Mi libro en progreso, Agile Software Architecture.
Mi Agile Architecture Workshop, que doy varias veces al año en distintas ciudades de América Latina
(cuando hay fechas programadas aparecen a la derecha)
Otros libros relacionados de colegas varios:

Building Evolutionary Architectures, de Rebecca Parsons, Neil Ford y Patrick Kua
Lean Architecture, de James Coplien y Gertrud Bjørnvig

Colaboración real: lo que más cuesta lograr en los equipos

2018-07-06T12:17:00.001-03:00

Trabajando con equipos que están adoptando Scrum (o algún otro framework ágil) suelo encontrarme escenarios como el siguiente:

Trabajan en iteraciones (o sprints)
Planifican al inicio
Revisan al final
Hacen retrospectivas (a veces) y tratan de mejorar

En muchos casos también tienen su reunión diaria (la daily standup o Scrum diario) y esos momentos suelen ser reveladores sobre qué están logrando como colaboración.

Antipatrón 1: cascada iterativa

Se nota al sincronizar que los miembros del equipo tienden a esperarse entre sí. Por ejemplo, alguien menciona que está terminando de diseñar X, que otro persona necesita para poder empezar a programar, para que finalmente otro pruebe...

Es frecuente en ese caso que algunos de los que no pueden continuar un item, inicien cualquier otra tarea (usualmente de menor prioridad) en la que no tengan trabas.

Obviamente, cuando se libera el ítem de más prioridad, es común que quede en espera hasta que se termine alguna de esas tareas menos prioritarias.

Antipatrón 2: sobre-especialización

También podemos notar que en diferentes momentos ciertos ítems se acumulan y quedan pendientes para un especialista en particular, dependiendo del momento en que estamos del proyecto. En algún momento puede ser que haya mucho por hacer en la interfaz de usuario, y la persona a cargo queda desbordada, mientras los demás, nuevamente, comienzan a trabajar en lo que puedan.

En el extremo, se nota en ciertas iteraciones que algunos de los miembros del equipo están llenos de trabajo, mientras que otros no tienen mucho que hacer.

La magia de trabajar de a pares

Es problema de estos escenarios es que ese grupo no está colaborando realmente. De hecho, no es un equipo ágil, sino un grupo con apenas un objetivo común, por más sincronización diaria que hagan.

Un equipo ágil se enfoca en la prioridad; en el valor de negocio. Por lo tanto, antes que iniciar ítems de menos prioridad, cada persona busca oportunidades de colaborar con quien ya inició un ítem más prioritario, con varios objetivos:

Tratar de terminar cuanto antes lo que tiene más valor
Ayudar a mantener el foco y evitar bloqueos mentales frecuentes cuando trabajamos solos
Aprender lo básico de las especialidades del resto del equipo, para que poco a poco muchas tareas triviales (que estadísticamente son la mayor parte de un proyecto) puedan ser resueltas por cualquiera.
Lograr mayor integridad conceptual en el producto, al compartir con todo el equipo una visión holística, donde el equipo entero es responsable por el total, y no por diferentes componentes o aspectos.

¿Todo hay que hacerlo de a dos?

No necesariamente. De hecho, aunque suena raro, si un equipo empieza a trabajar de a pares más frecuentemente, va aumentando la capacidad de cada miembro de encarar solo cualquier tarea. Pero a la vez aumenta la facilidad con que cualquiera puede pedir ayuda (cosa que para mucha gente es una enorme barrera) a otros.

Lo que suele ocurrir es que las personas tienden a trabajar solas en las tareas más sencillas y triviales (con un poco de aprendizaje, incluso las que están fuera de su especialidad) y les resulta casi natural reunirse y dividirse de manera fluida según sus necesidades.

Colaboración real en equipos

Dentro de los equipos ágiles, en definitiva, se busca que a través del aprendizaje colectivo podamos extender las capacidades de cada persona más allá de su especialidad. Esto no significa que ignoramos el estudio y experiencia acumulada de cada uno, ni que queremos que todos sean absolutamente expertos en todo.

Lo que busca un equipo ágil es aplicar el principio de Pareto a las capacidades individuales, es decir que cada persona aprenda aproximadamente el 20% de las especialidades del resto del equipo, que suelen resolver el 80% de su trabajo.

En definitiva, buscamos poder distribuir más uniformemente el trabajo, aprovechando al máximo los conocimientos muy específicos solamente en esos pocos casos en que se plantean problemas tan complejos que requerimos todo el poder del "experto".

Finalmente, esta forma de trabajo es la que apoya el principio ágil de enfocarnos en la entrega de valor, ya que nadie necesita estar haciendo nada que no sea de la mayor prioridad.

Literatura Potencial al Aire Libre

2018-04-22T13:18:00.001-03:00

Durante la reciente edición 2018 del Agile Open Camp, en Bariloche, Argentina, presenté una charla relámpago (21 slides de 20 segundos cada uno; 7 minutos en total) que titulé “Restricciones para la Creatividad” y en la que contaba sobre el Oulipo, el “Ouvroir de littérature potentielle” que en los años '60 fundaron en Francia escritores de diferentes orígenes, dedicado a explorar las posibilidades de restricciones auto-impuestas, surgidas sobre todo de las matemáticas y sus derivados (como la música o el ajedrez) para desencadenar procesos creativos.

Debajo queda la presentación, aunque son sólo imágenes. Pero más importante que eso, para mi, es el libro que tiene el mismo título que este post, resultado del taller que realizamos más tarde, durante una sesión del Open Space.

Los asistentes escribieron varios Haiku, y luego comenzaron cuatro cuentos, algunos de los cuales fueron finalizados días más tarde. El librito es una compilación de esos trabajos, más una breve introducción que recupera (con notas adicionales) parte de la charla relámpago.

Gracias a Marta Bendomir, Tommy Christie, Marcela Pelz y María Thompson por participar del taller y del libro, y gracias a Manuel Mandrafina Thompson que colaboró en el cierre de uno de los cuentos.

El libro puede descargarse en forma libre y gratuita desde aquí (o desde la imagen de tapa más arriba).