¿Qué hacer cuando "explota" una retrospectiva?

Hace poco participé en un meetup de Madriagil en que conversamos sobre temas de Agilidad en un fishbowl, en concreto lanzábamos preguntas de interés y discutíamos alrededor de estas. Una de las preguntas me llamó mucho la atención, así que con este post pretendo recoger el conocimiento que se generó, y enriquecerlo con mi experiencia.

Una retrospectiva desde fuera

Una retrospectiva "explota" cuando los miembros del equipo empiezan a culparse los unos a otros por todos los problemas acaecidos en el proyecto/producto. Esta explosión evidencia una larga serie de retrospectivas y prácticas ágiles mal llevadas, ocurre cuando se produce esa gota que colma el vaso.

Si llega a producirse esta situación lo que hemos de hacer como Scrum Masters es parar en seco la retrospectiva, esperar unos días para dejar reposar y enfriar las diferencias y los enfrentamientos entre los miembros del equipo, y después cambiar de contexto y espacio para dar los primeros pasos para la recuperación en el ritmo de restrospectivas.

Si en la compañía existiese la figura del coach ágil hablad con él, contadle y dejaos ayudar, y si no lo hubiese, apoyaros en otros Scrum Masters que pueda haber.

El mejor primer entorno para resolver es el lúdico, el que está totalmente desligado del trabajo y genere team-building, unas cervezas por ejemplo, la cerveza tomada con moderación tiene la propiedad de relajar las tensiones :-)

Para enfrentarse a la primera retrospectiva posterior haceros las siguientes preguntas:

• ¿Estamos todos preparados para una retrospectiva?
• ¿El equipo quiere mejorar y aprender cosas nuevas?
• ¿Afloran los sentimientos respecto al equipo/proyecto/producto en las retrospectivas?
• ¿Hay uno o dos miembros que dominen la conversación?
• ¿En las retrospectivas anteriores se han mantenido el foco?
• ¿El foco ha estado mayoritariamente en impedimentos exteriores cuya resolución no depende del equipo?
• ¿Se ha implementado una acción de mejora con cada retrospectiva?

Intentad manejar y gestionar las respuestas a esas preguntas, replantearos la manera en las que facilitáis y balanceáis las retrospectivas, incluid un área de agradecimientos si no la tenéis ya, resultará sorprendente lo que lleva a motivar esa idea tan simple.

Para medir la salud del equipo recomiendo la técnica del histograma de satisfacción.

Y recordad: si no haces retrospectivas no haces Scrum

Quiero dar mi agradecimiento a los participantes del meetup "Agile Manifesto: Back to Basics" en el que tratamos este tema, especialmente a Tino y a Antonio que fueron los que lo organizaron.

¿Cómo configurar las mesas de los equipos de Scrum?

Scrum tiene reglas muy simples pero difíciles de implantar, después de un camino nada fácil hemos conseguido por fin un par de equipos funcionando con Scrum, y ahora estamos preparándonos para el futuro trabajando en como configurar equipos Scrum en una sala con más de 10 equipos y 100 personas.

Tal como nos enseña Alistair Cockburn seguimos una de sus reglas:

"El equipo debe estar sentado con una separación no superior
a la longitud de un autobús escolar"

Estamos diseñando espacios exclusivos por equipo, de manera que el entorno facilite las prácticas de Scrum:

• Que estén juntos y puedan comunicarse cara a cara, no hay mejor comunicación, especialmente cuando se trata de cuestiones complejas.
• Que sea fácil colaborar y sentarse al lado de cualquier otro miembro.
• Que tengan su espacio y puedan realizar sus reuniones diarias de pie ante el tablero de Scrum.
• Que sea posible la comunicación osmótica; ocurre cuando los miembros prestan atención de forma automática, como por ósmosis, a conversaciones entre otros miembros que para ellos también son relevantes.

También es importante que los equipos tengan un poco de libertad para ajustar su entorno:

• Sillas con ruedas para que puedan moverse libremente en su espacio.
• Un tablero grande que sea cómodo y permita incluir otras áreas que les puedan ser útiles.

Para configurar las mesas hemos hecho una encuesta a los equipos de la sala y hemos diseñado dos patrones:

Dos patrones, equipos azules y rojos

Los equipos azules, los de la izquierda de la figura, son equipos que prefieren verse las caras en todo momento y que se sientan alrededor de la mesa:

• Todos los miembros tienen visión directa hacia los demás miembros.
• Tienen un espacio para las reuniones diarias y el tablero en un extremo de la mesa.
• Se pueden desplazar fácilmente en su lado de la mesa.

Los equipos rojos, los de la derecha de la figura, son equipos para los que la movilidad es importante y que se sientan alrededor del pasillo entre mesas:

• Todo el pasillo es su espacio.
• Celebran las reuniones diarias al final del pasillo ante su tablero.
• Cualquiera puede desplazarse al lado de cualquier otro miembro muy fácilmente.

Disposición de uno de los equipos rojos :-)

He observado que los equipos más maduros en Agilidad prefieren ser rojos, seguramente porque prefieren la comunicación cara a cara y la colaboración forma parte de su día a día, cuando hay algo que tratar se sientan unos al lado de los otros. Los equipos que prefieren ser azules suelen ser equipos que provienen de proyectos no ágiles. Cuando les pregunto si no es mejor tener facilidad de sentarse uno al lado de otros, me contestan que ellos prefieren quedarse en su sitio, situarse en el mismo código en su pantalla, y a partir de ahí hablar y discutir.

Finalmente hemos configurado la sala con equipos rojos a un lado y azules al otro. En el lado de los equipos rojos hemos utilizado los dos extremos de filas libres para dos equipos pequeños de 3 y 4 miembros.

¿Hay algún juego para crear e integrar equipos Kanban?

Tablero getKanban en el décimo día

Termino mis cursos de Lean-Kanban con una simulación muy completa que dura 3 horas y que consiste en experimentar los principios de Kanban, límites WIP, el sistema de arrastre y las diferentes herramientas y prácticas que propone Kanban. Utilizo la versión 2 del juego "The getKanban Board Game" que se puede descargar gratuitamente en formato pdf.

En el último curso que di, un alumno, que es jefe de proyecto, exclamó: "¡Este juego es ideal para crear equipos, muestra las fortalezas y debilidades de cada uno y nos integra como personas en un equipo!", fue tan revelador que apunté la frase y decidí en ese mismo momento que escribiría un post. Una vez terminado el juego siempre les pregunto a los asistentes por lo que han experimentado y sentido, y dicen frases como:

• Al principio nos teníamos que coordinar mucho, luego ya sabíamos que cada uno estaría haciendo lo suyo.
• Todos teníamos la misma visión completa del trabajo a realizar y del objetivo a alcanzar.
• La estrategia para decidir que tareas acometer salía de todos nosotros.
• Aunque explicitábamos las políticas escribiéndolas, todos las teníamos clarísimas.
• Sentimos como colaboramos y que formamos un equipo.

Este es un ejercicio del curso de Kanban de

El juego es un juego con una duración relativamente larga, 3 horas son suficientes para permitir una autentica interacción y hacer team-buidling entre los participantes. Es aplicable a todo tipo de equipos, desde equipos en que los miembros trabajan juntos a los que están deslocalizados. Se puede enfocar como una actividad lúdica convocando un sábado o fin de semana a todos los miembros, realizando el juego y luego redondeando el día con una comida o cena. :-)

Un hecho interesante que observo una y otra vez es que, aunque ofrezca $10.000 de premio al equipo que acabe antes, cada uno va a lo suyo y a su ritmo, no les motiva en exceso ese premio. Eso quiere decir que efectivamente acaban entrando en flujo y la motivación es el propio juego, el formar parte de y participar del juego como equipo.

Sobre el juego

Disposición de los jugadores, About the Game

El juego se juega en equipos de entre cuatro y seis personas, y a un juego por equipo. Cada equipo tiene un tablero que representa un tablero Kanban, y una colección de tareas u historias de usuario que representan los items del trabajo a hacer. Los equipos compiten para maximizar los beneficios mediante la optimización del flujo de trabajo.

Durante el juego los equipos elaboran gráficos a partir de los datos del juego, incluyendo un diagrama de flujo acumulado y un diagrama de control estadístico. Se producen eventos simulados durante todo el juego para desafiar a los equipos y obligarles a rediseñar sus estrategias, establecer prioridades y a tomar decisiones sobre la asignación de recursos.

Los gráficos del juego: diagrama de control estadístico, diagrama de flujo acumulado y análisis financiero

---

Para aquellos que quieran probar esta experiencia en remoto podéis utilizar Kanban Board Game, un simulador basado en Get Kanban Game versión 2. Cuenta con el mismo tablero, las mismas fichas, los mismos dados y los mismos gráficos que el juego original.

Tablero de la simulación en el día 9

Resultados en forma gráfica: diagrama de flujo acumulado, análisis financiero y diagrama de control estadístico

Quiero dar mis agradecimientos a The Fullmetal Agilist que con su artículo ¡Simulaciones Kanban a distancia! nos comparte su conocimiento sobre simulaciones Kanban :-)

¿Cómo escribir los criterios de aceptación?

Después de 50 años de historia de ingeniería de software hemos llegado a la conclusión de que los criterios de aceptación, que son el detalle de las historias de usuarios desde el punto de vista de testing y se traducen en pruebas, son un excelente lenguaje para especificar requisitos funcionales, y es por ello que toman tanta importancia en las historias de usuario.

Buenas prácticas con criterios de aceptación
Cortesía de Miguel Angel Sobrino

Para medir la calidad de un criterio de aceptación se utiliza el método SMART en el que se han de cumplir en lo máximo posible los siguientes criterios:

• S - Specific (Específicos)
• M - Measurable (Medibles)
• A - Achievable (Alcanzables)
• R - Relevant (Relevantes)
• T - Time-boxed (Limitados en el tiempo)

Se suelen escribir en forma de checklist o descripción de un flujo en cuanto se obtengan historias de usuario susceptibles de entrar en un sprint, y se acaban de refinar en la planificación de sprint. Los criterios de aceptación ayudan al equipo de desarrollo a entender el funcionamiento del producto, de manera que estimarán mejor el tamaño de la historia subyacente y, cuando el equipo se encuentre en fase de desarrollo servirá de guía cuando el desarrollador tenga que tomar una decisión, tomará la más acertada.

Finalmente, y a modo del viejo truco del palillo en repostería, como lo describe Tamara Vázquez en su post sobre criterios de aceptación, si se mete un palillo en la porción de tarta, que representa el incremento del sprint, y sale limpio, es que la porción de tarta está bien hecha, de la misma manera que el Propietario del Producto comprueba en la revisión de sprint, a través de estos criterios de aceptación y la definición de hecho, si la historia de usuario se puede dar como hecha y finalizada.

Diferentes formatos para escribir criterios de aceptación:

Comprobar [Criterios]

Demostrar [Comportamiento esperado]

Verificar que cuando [Rol] hace [Acción] consigue [Resultado / Comportamiento esperado]

Dado que [Contexto] y adicionalmente [Contexto] cuando [Evento]

entonces [Resultado / Comportamiento esperado]

Sintaxis gherkin para describir el comportamiento del software

Actualmente estoy acompañando a una serie de proyectos en los que estamos escribiendo los criterios de aceptación con el lenguaje natural, tal como el Propietario del Producto se expresa. Mirando hacia el futuro estamos planteándonos si escribirlos con la técnica del comportamiento por escenarios. Así, cuando implantemos BDD (Behavior Driven Development), los usuarios de negocio y los Propietarios del Producto estarán acostumbrados a escribirlos de esa forma, en concreto pensamos en implantar gherkin, el lenguaje específico creado especialmente para las descripciones de comportamiento de software. La sintaxis de gherkin es la siguiente:

(Scenario) Escenario [Número de escenario] [Titulo del escenario]:

(Given) Dado que [Contexto] y adicionalmente [Contexto],

(When) cuando [Evento],

(Then) entonces [Resultado / Comportamiento esperado]

Derivado de esta sintaxis los elementos de los criterios de aceptación son:

• Número de escenario: Número (ejemplo 1, 2, 3 ó 4), que identifica al escenario asociado a la historia.
• Título del escenario: Describe el contexto del escenario que define un comportamiento.
• Contexto: Proporciona mayor descripción sobre las condiciones que desencadenan el escenario.
• Evento: Representa la acción que el usuario ejecuta, en el contexto definido para el escenario.
• Resultado / Comportamiento esperado: Dado el contexto y la acción ejecutada por el usuario, la consecuencia es el comportamiento del sistema en esa situación.

Ejemplo:

Partimos de la siguiente historia de usuario:

Como cliente

Quiero retirar dinero del cajero automático

Para poder evitar ir al banco a hacer una cola

y escribimos los criterios de aceptación en gherkin:

Escenario 1: Cuenta tiene crédito

Dado que la cuenta tiene crédito

y que la tarjeta es válida

y que el cajero tiene dinero disponible

Cuando el cliente pide dinero

Entonces la cuenta es debitada

y el dinero es entregado al cliente

y el cliente recupera su tarjeta

Escenario 2: La cuenta excede el límite negativo acordado con el banco

Dado que la cuenta excede el límite negativo acordado con el banco

y que la tarjeta es válida

Cuando el cliente pide dinero

Entonces el cajero muestra un mensaje negando el pedido

y el dinero no es entregado al cliente

y el cliente recupera su tarjeta

Plantilla para criterios de aceptación,
cortesía de La Oficina de Proyectos de Informática

PMOInformática.com nos propone una excelente plantilla para recoger y documentar las historias de usuario y sus criterios de aceptación, plantilla que está libre de derechos de autor y puede ser usada libremente (descargar plantilla) :-)

En su página muestran el siguiente ejemplo de un criterio de aceptación:

Escenario 1: Dado que existe una categoría sin productos asociados, cuando el cliente despliegue el listado de categorías para realizar su búsqueda, entonces el sistema mostrará el siguiente texto al lado de la categoría "Actualmente no poseemos productos para esta categoría".

¿Existe alguna dinámica lúdica para hacer team-building?

Cartel anunciando la dinámica en el bar

Pues sí las hay, voy a presentar la dinámica lúdica que Allan Rennebo nos enseñó con su Beer Taste Kanban durante el Scrum Coaching Retreat 2015 en Alemania. Fue una de las propuestas Open Space programadas para las actividades vespertinas.

Esta dinámica está indicada para después de la jornada laboral, es muy recomendable no practicarla si hay que volver a la oficina. :-P

Jugar la dinámica en un bar de confianza no debe de preocuparnos por el hecho de desembarcar con un flip-board en el mismo y marcar las casillas en una mesa con cinta de carrocero. Los camareros y barmans han visto cosas mucho más increíbles, jajajaja, así me lo dijo el del bar donde jugamos.

Así es como funciona:

• No hay límite de participantes, el límite serán el tamaño de la mesa y el tablero.
• Preparamos el tablero con los siguientes estados: Ready (Listo), Tasting (Catando) y Done (Hecho).
• Colocamos tantos post-its en la columna Ready como variedades de cerveza se van a catar, apuntamos la variedad en el post-it.
• Preparamos la mesa con seis casillas que etiquetamos del 1 al 6 con post-its. Los números representan la valoración de la cerveza, siendo el 6 la valoración más alta y el 1 la más baja.

Mesa preparada para el Beer Taste Kanban

• Preparamos tantas cañas, preferiblemente pequeñas, como participantes y variedades de cerveza se van a estudiar. Por cada participante habrá una caña de cada variedad de cervezas.



Participante ante la pizarra

• Empezamos con un WIP = 4 en la columna Tasting, eso quiere decir que solo puede haber 4 participantes bebiendo su cerveza a la vez.
• Por cada tipo de cerveza hacemos una ronda, al cambiar de ronda variaremos el WIP.
• Uno de los participantes se le da la responsabilidad de cronometrar.
• Decidimos que variedad vamos a probar, apuntamos el WIP y movemos el post-it a Tasting.
• A la voz de "YA"  del cronometrador tantos participantes como permita el WIP beben una caña de la variedad lo más rápido que pueden, y colocan el vaso vacío en la casilla que corresponde a su valoración. Con cada vaso colocado en la mesa se libera un elemento del WIP y otro participante puede beber su cerveza.
• Cuando todos hayan catado y colocado los vasos vacíos en la mesa, sumamos todas las valoraciones y las apuntamos en el post-it.
• El cronometrador para el reloj y apunta el tiempo en el post-it y finalmente lo mueve a Done.
• Hacemos una breve retrospectiva y decidimos el WIP para la siguiente ronda.
• Pasamos a la siguiente ronda.

El objetivo de la dinámica es averiguar cuál es el WIP que minimiza el tiempo de servicio para valorar una variedad dada de cerveza.

Después de 5-6 variedades de cerveza las medidas no son muy poco fiables, jajaja, pero el objetivo principal de la dinámica se habrá cumplido, habremos hecho team-building.

Una de las conclusiones que hemos sacado del juego es que el tiempo se minimiza con WIP = 1. Os invito a jugar y a sacar vuestras propias conclusiones... una cosa si os aseguro, serán conclusiones muy alegres y coloridas.

Many thanks to Allan Rennebo who teached me this game and played it with us :-)

¿Existe algún tablero para hacer seguimiento de las interacciones de un coach ágil?

Una de las misiones fundamentales de un coach ágil es la de abrir canales de comunicación entre todos los interesados de la compañía, incluido él mismo. Uno de los pilares de la Agilidad es la comunicación, tal como dice el primer valor del Manifiesto Ágil:

Individuos e interacciones sobre procesos y herramientas

Hasta existen técnicas de retrospectiva, como el Triangulo Retrospectivo, que se basa en analizar las interacciones entre los distintos roles e interesados.

My personal interaction matrix

Uno de los grupos de trabajo del Scrum Coaching Retreat 2015 de Alemania trabajó en una caja de herramientas para el coach y entre ellas estaba este tablero con una matriz de interacciones personales que quiero mostrar en este post.

Su propuesta consta de tres columnas:

• En la primera se colocan los diferentes grupos con los que interactuamos como coach (gerencia, mandos intermedios, líderes de equipo o Propietarios del Producto, equipos de desarrollo e individuos)
• En la segunda columna, encabezada por un 1, anotamos con un palito cada interacción con el grupo que haya habido durante el sprint. A final de sprint debe de haber una distribución equilibrada de interacciones en forma de curva de Gauss: alguna interacción con gerencia e individuos y bastantes con el resto de los grupos. La carencia de interacciones con alguno de los grupos indicará en dónde trabajar para el próximo sprint.
• En la tercera columna, encabezada con "week 2", se pone un post-it por cada interacción importante ocurrida durante el sprint. En los post-its figuran el coach y su interlocutor, se anotan los nombres y algunas palabras clave expresadas por cada uno y en la cara se dibujan caritas alegres o tristes. Interacciones exitosas tienen una carita alegre, e interacciones problemáticas una carita triste. De esta forma sabemos cuáles son las interacciones sobre las que hay que trabajar para el sprint que viene.

Voy a poner en marcha mi propio tablero y contaré en este mismo post cuál es mi experiencia :-)

Many thanks to Scrum Coaching Retreat 2015 group that designed this matrix.

¿Qué hace que Scrum esté alineado con la naturaleza humana?

La psicología de Scrum

Recientemente he leido un libro interesantísimo, se trata de "Scrum" de Jeff Sutherland. En él Jeff nos cuenta como después de haber visto un robot insectoide en que cada pata tenía su propio procesador, se preguntó: ¿Qué ocurriría si pudiéramos dar con un conjunto de reglas que hicieran que las personas trabajaran en equipo como hacen esas patas?

Para poder dar con estas reglas Jeff tuvo que desgranar la naturaleza humana para construir sobre esta en vez de ir en contra de la misma. Inició una aventura que describe de forma muy amena en su libro. En este post he extraído la parte de sus ideas sobre la psicología de Scrum para que podamos comprender porqué Scrum no es una "metodología" más, es un marco de personas para personas.

La multitarea

---

En la naturaleza del ser humano no está la multitarea

Uno de los mayores enemigos de la productividad es lo que llamamos multitarea, realmente se trata del cambio continuo de contexto de una actividad a otra.

¿Cómo ataja Scrum esta problemática tan común en tantos profesionales de las TI?

• Con sprints cerrados en los que nadie externo interfiere, dando así una oportunidad real al equipo para autogestionarse. Cuántas veces hemos pensado que trabajaríamos mejor si nos dieran las tareas a hacer y nos permitieran organizarnos a nuestra manera hasta acabar con todas ellas.
• Con un sistema de arrastre (pull):
• Es el equipo el que decide cuantas historias de usuario entran en el sprint, son ellos los que arrastran la pila de sprint desde la pila de producto.
• La autoasignación en la reunión diaria, no hay un jefe de proyecto que distribuye tareas, las tareas se asignan en equipo de una en una.

Síndrome del estudiante

---

Este es un fenómeno que forma parte de la naturaleza humana por el cual las personas nos espabilamos y comenzamos a dedicarnos seriamente a una tarea cuando la fecha en que esta debe de terminarse se acerca, y eso lo sentimos en forma de estrés. En motivación se estudia que es bueno tener un objetivo bien definido a largo plazo, pero aún mejora mucho cuando las tareas se dividen en tareas pequeñas con objetivos sencillos y a corto plazo.
¿Cómo incorpora Scrum esta característica de la naturaleza humana? 

Con sprints que resultan en un incremento potencialmente instalable en producción con una fecha de entrega cada pocas semanas. De esta manera se focaliza al equipo en las tareas del sprint, en entregas muy cortas que son factibles finalizar sin esfuerzos.

Al principio el equipo sentirá estrés, se activará ante el peligro inminente, pero una vez rodado, Scrum genera un tono de ritmo de trabajo sostenido. Tiene que ver con el constructo arousal, la activación general fisiológica y psicológica del organismo, que describe los procesos que controlan la alerta, la vigilia y la activación, que Scrum sitúa en el nivel óptimo. Las personas creamos y somos creativas cuando existe ese nivel de tensión.

Límites de la memoria de trabajo

---

La mente - Cortesía de Pixabay

La memoria de trabajo es nuestra memoria activa que contiene la información que estamos utilizando en este momento, y, solo somos capaces de "pensar" (hacer deducción lógica, correlación, búsqueda de patrones, ejecución de tareas, etc.) con lo que hay en esta memoria de trabajo. Tal como demuestra la teoría de George Miller, esta memoria consiste la que es capaz de almacenar a la vez informaciones durante alrededor de 15 segundos con una capacidad limitada de 7±2 elementos.

¿Cómo se adapta Scrum a esta limitación de la memoria?

• Evidentemente la multitarea es enemiga de la memoria de trabajo a corto, si tenemos 7 elementos en nuestra memoria y si antes de 15 segundos, antes de que nuestro cerebro la haya clasificado como relevante y archivado en la memoria de largo plazo, la llenamos con 7 nuevos elementos, los primeros simplemente se pierden... ¿cuántas veces llegamos a casa después de un día agotador y nos damos cuenta de que íbamos a devolver una llamada y nos hemos olvidado totalmente? Como hemos visto en el primer punto, Scrum resuelve la multitarea.
• ¿Porqué la dinámica de equipos se deteriora con de equipos por encima de 7 a 9 miembros? En primer término esto ocurre por la memoria de trabajo, no somos capaces de interactuar y mantenernos en línea con más de ese número de personas a la vez. En segundo lugar por la dinámica de grupos que refleja el conjunto de fenómenos que interactúan en las relaciones personales entre los miembros de los grupos que en general estimulan la emotividad, creatividad, dinamismo y tensión positiva, y en caso de grupos mayores de 8-9 miembros da lugar a aparición natural de roles. Algunos roles van a favor de los equipos integrados, como el portavoz y el líder, pero otros van en contra, como el chivo expiatorio, el gracioso, el pasota y el saboteador. Es por todo ello que Scrum habla de equipos de 3 a 8-9 personas. Si nos situamos en nuestras experiencias como miembros de equipos grandes, lo que podemos observar es que se forman grupos dentro del equipo, y sentimos el equipo a través de ese grupo, los de fuera del grupo sabemos que son parte del equipo, pero realmente no los sentimos como parte.

La confianza

---

Confianza - Cortesía de Pixabay

Las personas tenemos un bloqueo natural para no confiar en alguien que no conocemos. Es por ello que todos los elementos de Scrum propician la comunicación directa cara a cara entre las personas.

En caso de equipos distribuidos es recomendable hacer un evento lúdico para juntar a las personas un fin de semana para que se conozcan, de esa manera se establece confianza. Quienes hayan trabajado con personas de otro continente habrán vivido que todo se "agiliza" muchísimo una vez se hayan conocido en persona a quién está al otro lado.

Cansancio y productividad

---

Las personas tenemos límites en nuestra actividad mental, cuando nuestro cerebro trabaja libera radicales libres de oxigeno que nuestro organismo tiene que evacuar. En nuestra actividad mental diaria producimos radicales a un ritmo superior al que nuestro cuerpo es capaz de evacuar, es por ello que necesitamos descansar y dormir. Así queda limitado el volumen de decisiones que somos capaces de tomar al día. Cuando estamos cansados tomamos decisiones a la ligera que resultan en malas decisiones y cometemos un mayor número de errores, desperdiciando gran cantidad de energía.

Nuestra productividad varía a lo largo de la jornada de trabajo, la mayor productividad ocurre entre las 4 y 6 primeras horas. Después de muchas horas la productividad se aproxima a cero, incluso puede convertirse en negativa.

Cuando trabajamos en un proyecto en cascada nuestra productividad máxima se produce con unas 50 horas semanales (ver la gráfica con la curva de Maxwell a la izquierda), en este tipo de metodología trabajamos solos y nuestra actividad mental va a un ritmo relajado. Cuando trabajamos con Scrum estamos muy conectados con el equipo y muy focalizados en el trabajo, ganamos en productividad lo que implica más actividad mental. El máximo de productividad bajo Scrum se produce entre las 30 y 40 horas semanales.

Scrum es contrario a los esfuerzos, "no queremos héroes" del sobreesfuerzo. Aconseja 40 horas semanales de las cuales se deben de ocupar un 80% en tareas productivas, el restante 20% es necesario como buffer entre tareas para pequeños descansos y para poder absorber la variabilidad (aquellas cosas no previstas que ocurren a todos los niveles). Es recomendable hacer pequeños descansos cada hora, hora y media o dos horas, de esta manera evitamos la sobrecarga.

Un problema usual que sufren a menudo los equipos de TI es que algunos directivos o jefes de proyecto no saben cómo medir su productividad. Suelen ser directivos sin capacidad suficiente para medir los resultados, así que se obcecan en medir los medios o el proceso, es decir, las horas dedicadas, y no el resultado de esas horas de trabajo.

El ritmo

---

Calendario que marca el ritmo (cadencia) de las reuniones
de Scrum - Cortesía de Pixabay

El ritmo es otro de los puntos clave de la naturaleza humana, la vida es un fenómeno rítmico. La actividad de cualquier ser viviente es un fenómeno que se manifiesta siempre con una variación regular y no como un proceso continuo, de ahí se habla del ritmo biológico. La naturaleza también ocurre a ritmos (día y noche, estaciones, lunas,…) y somos nosotros los que nos hemos adaptado a estos ritmos incorporando los nuestros propios.

Las personas estamos acostumbradas a ritmos, a rutinas a hábitos. Aunque nos guste la variación y hacer cosas nuevas de vez en cuando, solemos considerar que es bueno hacer cada día las cosas de la misma manera ya que de esta forma obtenemos un orden en nuestras vidas.

Scrum crea hábito al proporcionar sprints regulares con sus reuniones regulares con su apertura y su cierre, crea un ritmo de espacios mentales para incorporar todo aquello que puede ocurrir en la construcción de un producto. Fijémonos que con Scrum podemos programar nuestra agenda con un año o más por adelantado, sabemos las reuniones que ocurrirán, el objetivo y agenda de las mismas, aunque no el contenido concreto. Scrum está concebido para imprimir un ritmo que sea sostenible y que se pueda mantener indefinidamente en el tiempo.

Planificación a corto

---

Equipo planificando

Los seres humanos necesitamos cierto orden y cierta previsibilidad sobre lo que ocurre a corto plazo. Cuando tenemos varias tareas en mente necesitamos eliminar todo ruido posible y no tener que estar pensando en qué va antes y qué después. La manera que tenemos los seres humanos para realizar esta limpieza es a través de la planificación, pensar antes de actuar para estudiar de manera anticipada nuestras metas y acciones. Así obtenemos un plan a corto que refleja el trabajo que tenemos que hacer, y eso nos permite estar enfocados en simplemente realizar las tareas. La planificación a corto actúa directamente sobre el estrés, dejamos de sentir que las tareas nos desbordan y que trabajamos de forma impulsiva.

En Scrum planificamos cada sprint para obtener la pila de sprint, un paquete de tareas en equilibrio con nuestra capacidad de trabajo y en el que en alto grado hemos reducido toda incertidumbre. Así tenemos un plan que nos hace sentir que no empezamos en falso, y del que estando convencidos de su factibilidad refuerza nuestro sentimiento de compromiso y nuestra motivación.

La estimación

---

Las ramificaciones de la mayoría de las plantas
son un número de la serie de Fibonacci

Como explica Kahneman, las personas, debido a sesgos y heurísticos, somos muy malas estimando cosas como tiempos, tamaños, pesos y volúmenes de forma absoluta. En cambio somos muy buenos estimando en relativo, comparando una cosa con otra, por ejemplo el tamaño relativo entre un pingüino y un caballo que todos situaríamos entre el 8 y el 13. Nos pasamos la vida comparando cosas.

Además resulta que somos buenos utilizando la serie de Fibonacci, no distinguimos bien entre 5 y 6 y 7 pero si entre 5 y 8. Esto ocurre porque la serie de Fibonacci está en todas partes en la naturaleza, como en la mayoría de las plantas y los cristales, y también en nuestra cultura como en la música, la arquitectura y la pintura.

Vivimos inmersos en proporciones de la serie de Fibonacci, hasta el punto de que todo aquello cuyas proporciones cumplan con el cociente de dos números de la serie, el número áureo, lo consideramos bello. Esto muestra lo increíblemente adaptativos que somos, muestra nuestra gran inteligencia "natural".

¿Cómo incorpora Scrum estas características de la naturaleza humana?

• Mediante la estimación relativa de historias de usuario en base a la unidad punto de historia.
• Y la estimación con la baraja de planning poker que se basa en la serie de Fibonacci.

Errar

---

A través de error aprendemos y llegamos al éxito
Cortesía de Pixabay

Errar es humano y el error, la prueba/error, es el proceso en que el ser humano aprende y evoluciona, fallamos antes de tener éxito porque hemos de aprender, el fracaso es el esfuerzo mal dirigido y hemos de aprender a dirigirlo.

Fallar es parte del proceso y una de las ventajas de Scrum es que propicia el fallo temprano, aunque el término correcto es aprender, y por tanto Scrum propicia el aprendizaje temprano.

Para quitar el miedo a errar y para reforzar la autocrítica, cuando un miembro de los equipos que acompaño como Scrum Master descubre o muestra un error que ha cometido, el resto del equipo le aplaude ya que la detección temprana del error evita problemas que pudieran ser mucho más graves en el futuro. Por ello no hay castigos ni premios en Scrum, simplemente cogemos el feedback, nos arremangamos las mangas y tiramos para adelante. Scrum si incorpora el reconocimiento, con cada revisión de sprint al revisar los criterios de aceptación, se reconoce implícitamente el trabajo bien hecho.

Como decimos los coaches ágiles "Si has de fallar te ayudaré a fallar en dos semanas".

La autoorganización

---

La colmena resultado de la autoorganización de las abejas
Cortesía de Pixabay

Los seres humanos, igual que en el reino animal, tenemos aptitudes innatas para la autoorganización. Fijémonos en las colmenas de las abejas, en las bandadas de pájaros, en la complejidad de los hormigueros, en los bancos de peces... la naturaleza está llena y es autoorganización.

Los seres humanos cuando nos juntamos en grupos nos autoorganizamos de forma automática, formamos equipos, gruposm, tribus y redes sociales.

Fijémonos qué ocurre cuando se junta un grupo de niños que no se conocían previamente: en cuestión de minutos están jugando como si fueran amigos de toda la vida. Scrum se basa es equipos autoorganizados que encuentran sus propias formas de coordinarse y hacer las cosas, formas ajustadas a ellos mismos, que hacen que trabajen de forma motivante y proactiva. Un equipo autoorganizado es mucho más que la suma de sus partes... genera cosas increíbles...¡y se lo pasa bien!

Mis agradecimientos a Jaime Santos y a Claudia Menzinsky, estudiantes de psicología que enriquecieron con su conocimiento este post, en especial a Jaime quien me ayudó a revisar el contenido.