domingo, 11 de octubre de 2015

¿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?
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?
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.

sábado, 10 de octubre de 2015

¿Cómo lidiar con los ejecutivos para transmitir Agile?

Fotos del evento
La base para transmitir a nuestros ejecutivos trata de empatizar y en establecer confianza:
  • Para empatizar conozcamos en la media de lo posible su día a día, busquemos sus intereses y preocupaciones, observemos su rutinas para buscar el momento, el lugar y el lenguaje adecuado para transmitirles nuestro mensaje.
  • Para establecer confianza empecemos por nuestra confianza en nosotros mismo, reforcémosla con ejercicio y conocimiento, y para ganar la de nuestros ejecutivos tengamos muy claro el mensaje y transmitámoslo con seguridad y confianza en nuestras palabras. Y si nos equivocamos, admitámoslo sin más, ese gesto también refuerza la confianza.
Quiero exponer un checklist para coaches ágiles que contiene puntos que nos pueden ayudar a hablar a nuestros ejecutivos. Lo elaboramos en el Scrum Coaching Retreat 2015 en Alemania, evento en el que coincidimos una cincuentena de coaches para compartir nuestra experiencia y buscar de forma colaborativa respuestas a preguntas comunes.

Uno de los temas que tratamos de forma colaborativa fue este, aplicando Scrum obtuvimos este checklist que voy a presentar. Consta de dos partes, una interna para el coach, que trata de cómo puede prepararse, y la segunda externa, con aquellas cosas que le pueden ayudar a lidiar con los ejecutivos.

Checklist Ejecutivos
Interno para el coach

☐ Expande tus límites
construye compenetración, aprende a hablar al CEO
  • Lee los informes que ellos leen // libros que ellos leen // …
  • Recomienda opciones, deja que ellos decidan
  • Se consciente de su tiempo
  • Encuentra lo que les preocupa
  • Aprende su lenguaje y vocabulario informático
☐ Qué es de su interés
☐ Ten confianza // Construye confianza
Irradia confianza
  • Expande tu zona de confort
    ppt karaoke – practica retórica – asiste a cursos – ejercita la improvisación
  • Toma consciencia del lenguaje corporal
  • Consigue un mentor // Haz de mentor
  • Ejercita el acondicionamiento mental
  • Practica y entrénate en entornos de confianza // Habla en público en entornos de confianza
☐ Expande tu conocimiento

Externo para el coach

☐ Dale un plan de alto nivel

☐ Inputs y evidencias de 3 a 5 minutos
☐ Conoce la agenda de tus ejecutivos // Abórdalos cuando tengan tiempo

☐ Comparte información con aquellos que le reportan a él directamente

☐ Facilita / recomienda su red de operaciones - Reuniones / llamadas con otros CEOs de una compañía ágil

El checklist original con puntos de como prepararse y lidiar con los ejecutivos 
Descargas / Downloads
Thanks to the great team "The Polyglots" that made it possible: Abisola Fatokun, Adam Mitchell, Jasmine Zahno and Silvana Wasitova.

viernes, 9 de octubre de 2015

¿Cómo se crea una arquitectura de software ágil?

Recientemente estuve en un curso de Raúl Herranz del que me gustó mucho como trató uno de los temas que más cuestan de transmitir, la arquitectura de software ágil. En su curso se basó entre otras en el artículo de Diego Fontdevila y Martín Salías "Software Architecture in the Agile Life Cycle".

En Agilidad desaparece la figura del arquitecto de sistemas que crea arquitectura, y esta se envía hacia abajo, es el propio equipo el que hace emerger la arquitectura de software y esta es recogida posteriormente por el área de arquitectura que crea estándares basados en experiencia real. Ocurre algo semejante la figura del jefe de proyecto, que es inexistente, y cuya gestión que es superada con creces por la autoorganización del equipo.

Recordemos el undécimo principio del Manifiesto Ágil:

Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados

Nos está diciendo que la responsabilidad compartida diluye el rol tradicional de arquitecto, que la arquitectura es creada por el equipo y este participa al completo en el diseño, comprendiendo las implicaciones de las decisiones de diseño, y evaluándolo de manera continua.

Mencionaré dos aproximaciones arquitectónicas: 

SASHIMI

APIs a modo de lonchas de sashimi
Trata de ir construyendo la arquitectura a base de ir agregando APIs a modo de finas lonchas de sashimi hasta llegar a la arquitectura deseada, a modo de símil la arquitectura emergerá como el salmón al agregar las lonchas.

Trata de de construir la cantidad mínima de código de infraestructura para conectar todas las piezas del sprint, Mínimo Producto Viable (MPV), o release, y empezar a construir para dar una rápida experiencia de los resultados tanto al equipo como los interesados de negocio. El foco está a nivel de API, estas se escriben con una implementación emergente. En algún momento cuando lleguen pruebas de carga, o de estrés quizá, se requiera de un tuning fino para aumentar la robustez de estas APIs, ese será el momento de adaptar y refactorizar.

CEBOLLA

La arquitectura en cebolla se basa en una aproximación en cinco pasos:

Visión técnica: es de alto nivel y proporciona una línea base conceptual que servirá como punto de referencia para enfocar el trabajo futuro y chequear la necesidad de realizar refactorizaciones. 
Arquitectura ágil en cebolla

Módulos: establece el conjunto de módulos de servicio que proporcionan valor real a los usuarios, se basan en una separación coherente de funcionalidades, por ejemplo módulos de facturación, contabilidad, seguros, créditos, seguridad...

Capas y niveles de solución
- Las capas son diferentes niveles de abstracción en términos de valor a nivel de usuario, por ejemplo: presentación, lógica de negocio y datos.
- Los niveles son la forma en que las capas lógicas se encuentran distribuidas de forma física, por ejemplo sistemas cliente/servidor son a dos niveles.

Componentes y servicios: define los componentes y servicios como piezas empaquetadas de software cuyas funcionalidades son muy específicas y están definidas por sus interfaces.

Clases y funciones: finalmente, en nivel más alto está este en que los miembros del equipo escriben el código en lenguajes de programación y ficheros de configuración.

Todos los niveles de la arquitectura en cebolla son refactorizados continuamente sin perder la sincronía. Los niveles inferiores se suelen estabilizar antes, la refactorización es como una ola de abajo a arriba que se va absorbiendo de manera que la visión técnica sea la más invariable.

Como hemos visto el equipo al completo participa en el diseño, en la práctica lo hace con:
  • Discusiones sobre arquitectura en las reuniones de planificación de sprint y revisión de sprint.
  • Reuniones de diseño donde el equipo expone sus ideas abiertamente frente a una pizarra o una hoja de rotafolio en blanco.
  • Exponiendo permanentemente las guías de diseño, incluyendo diagramas, checklists y diagramas de referencia en las paredes de la war room.

sábado, 3 de octubre de 2015

¿Existe alguna dinámica para mostrar la potencia de la autoorganización?

Escribo este post desde el Scrum Coaching Retreat 2015 en Alemania para describir una dinámica en la que he participado, que en principio está pensada para romper el hielo y que pone de manifiesto la potencia de la autoorganización. Es una dinámica muy simple que se llama el nudo humano (human knot).

En paralelismo con los proyectos de software trata de deshacer un nudo humano con las instrucciones de un jefe de proyecto y compararla con lo que ocurre cuando dejamos que el propio equipo se autoorganice y lo haga.

Como crear el nudo:
  • Se forma un círculo con los participantes, el número aconsejable es alrededor de 8, se cierran los ojos, se extienden las manos hacia adelante y se agarran dos manos al azar, una con cada mano.
  • Luego se comprueba que es un solo círculo cerrado: uno de los participantes aprieta una de sus manos y el que es apretado propaga el apretón aparentando su otra mano. El círculo es único si al iniciador le llega un apretón a la otra mano. Si no fuera así hay que empezar de nuevo.
The human knot, thanks to the scrum coaching retreat participants
Primero enfocamos la solución de forma clásica, un "jefe de proyecto", que no forma parte del nudo, da instrucciones a los participantes para deshacer el mismo. En nuestro caso, con seis personas, el nudo se deshizo en 5 minutos y medio. Hay veces que un jefe de proyecto no es capaz de deshacer el nudo y hay que cancelar el juego.

En la segunda ronda dejamos que los participantes lo deshagan por sí solos, de forma autoorganizada y emergente, nuestro tiempo para deshacerlo fue de ¡24 segundos!

Como jefes o como líderes podemos ser el mayor experto en una materia determinada y también el más inteligente de la compañía. Pero como tal jamás podremos tener la diversidad de opiniones y perspectivas que tiene un equipo, y eso hace que un equipo en conjunto sea mucho más que el más experto y/o el más inteligente. Por tanto, el delegar las decisiones frecuentes en un equipo autoorganizados es la decisión más inteligente que pueda tomar un jefe o líder. Esta dinámica muestra precisamente esto de una forma muy directa y simple, muestra de lo que es capaz un equipo autoorganizado.

Para un coach ágil esta dinámica es aplicable en la formación a directivos, estos suelen ser bastante autónomos en su trabajo y sirve para hacerles sentir la autoorganización de los equipos, algo que si desconocen sienten como algo lejano.
Resolviendo el nudo humano de forma autoorganizada, 18 segundos frente a 268 con jefe de proyecto!!!

domingo, 27 de septiembre de 2015

¿Existe algún juego de simulación de Scrum que no sea relacionado con las TI?

Este es un ejercicio del curso de Scrum de
Hace poco me tocó dar un curso de Scrum a un grupo de alumnos de los que la mitad no provenían de las TI, había entre ellos algún psicólogo, un biólogo, gente de marketing... en fin, tuve que buscar y dar ejemplos provenientes de otros campos. Tuve pensar en qué tipo de simulación de Scrum realizar para hacerles vivir una construcción de algo no relacionado con informática a través de sprints y las ceremonias de Scrum.

Materiales para la simulación
Uno de los juegos más comunes es la construcción con Lego, yo mismo participé en la construcción de un pájaro de lego en mi certificación en 2011. Para el curso tenía que ser algo que se pudiera construir con materiales que tenía a disposición y fáciles de transportar: post-its, papel de rotafolios, hojas DIN-A4, rotuladores, tijeras, pegamento de barra... y recordé la simulación de Scrum para construir un resort vacacional de Carlos Peix.

Este juego dura dos horas y es para equipos a los que se explica por primera vez Scrum. Permite que hagan una simulación de creación de la pila de objetivos priorizada por releases (pila de producto) y de ejecución del propio proceso de Scrum, para que puedan comprobar los principales beneficios de Scrum, especialmente los referidos a alineamiento con las expectativas del cliente a base de inspección y adaptación.

La simulación empieza por una actividad de 15 minutos de duración, un User Story Mapping para obtener la pila de producto y luego priorizada a través de una Release Planning. Según vemos en la imagen que sigue y en la hoja de rotafolio izquierda:
  • El equipo identifica su hoja de ruta, aquellos servicios genéricos que van a dar en su resort, por ejemplo restauración (representado dónde el número 1).
  • Luego identifica por cada servicio las historias de usuario asociadas, en este caso lo que compondrá el resort y aquellos servicios concretos que dará, por ejemplo restaurante chino, restaurante gourmet, etc.
  • En función del valor de cada historia el equipo agrupa estas por releases, las aperturas de nuevos servicios a los turistas (en la imagen de R1 a R4, la primera representada con el número 2).
Planificación de Release y scrumboard de la simulación
A partir de la planificación de release la simulación entra en la fase de construcción mediante el marco de Scrum. La simulación consta de 3 sprints reflejados en el scrumboard sobre la hoja de rotafolios de la derecha (el sprint 1 está representado con el número 3).

Primero se asignan los roles, el Propietario del Producto será el trainer y por parte de los participantes se designa el Scrum Master y el resto serán el equipo de construcción. El Scrum Master se encargará de controlar los tiempos y de velar que las reglas Scrum se apliquen correctamente.

Los pasos para cada uno de los 3 sprints son:
Pila de producto de servicios del resort
Aquí muestro algunos ejemplos de feedback de Propietarios del Producto que yo utilizo:
  • Zarandeo la mesa diciendo que es una zona con terremotos frecuentes y el resort tiene que estar preparado para resistir a estos. Probablemente se producirán destrozos y explico que estos son por falta de calidad y por tanto hay que mejorarla, así como crear un sistema antiterremotos y anclar edificios y/o terreno.
  • Explico que observado el tipo de turistas que hasta la fecha han venido al resort, hemos visto que son adinerados y generalmente vienen con su propio yate, por tanto hay que construir un muelle para que puedan atracar en el resort.
  • Un estudio de mercado ha revelado que lo que buscan los turistas es que los bungalows más lujosos incluyan una piscina particular, es de importancia máxima construir estas piscinas.
  • Las compañías de cruceros han mostrado gran interés por hacer escalas de una noche, es prioritario construir un barco transbordador, su muelle y un hotel de alta capacidad para estos turistas de crucero.
A medio juego pongo a prueba si los participantes han comprendido las reglas de Scrum, me presento a medio sprint como un jefe o directivo clásico y les digo que es absolutamente prioritario construir un chiringuito o un gimnasio intentando cambiar y romper el sprint. Lo que debería de ocurrir es que el equipo lograse se diplomático, no se comprometiese y me derivara hacia el Scrum Master. Este debe de exponer argumentos de porqué no romper el sprint desde la perspectiva de Scrum, y finalmente llamar al Propietario del Producto para dar argumentos desde la perspectiva de negocio. Sólo el equipo puede cambiar un sprint, solo este y de la mano de Propietario del Producto podría proponer alguna solución, como por ejemplo un intercambio de historias. Si el equipo decide que no pueden incluirlo en este sprint hay que respetarlo, si les obligáramos a hacerlo romperíamos el sentimiento de compromiso auténtico de estos, dejaría de ser un equipo comprometido y motivado.

Aquí os muestro como quedó un resort resultante de un de los cursos de Scrum :-)
Finalmente se dedican 10 minutos a reflexionar sobre la simulación:
  • Sobre el alcance variable de Scrum, sobre como el equipo ha trabajado orientado a completar objetivos prioritarios y si ha sido flexible con los cambios.
  • Como las revisiones regulares del incremento han permitido conocer la velocidad del equipo y como se han alineado con las expectativas de todos.
  • Como en el primer sprint han sentido el estrés al traer todos los riesgos al principio del proyecto, y de cómo este estrés ha ido menguado con cada sprint.
  • Sobre como las acciones de mejora de las retrospectivas han afectado a los sprints posteriores.
Curso Scrum Manager de Estratecno de abril 2017: 3 equipos en plena simulación :-) Gracias a todos los participantes
Los resorts obtenidos en esta simulación suelen ser muy atractivos y coloridos, me llamó la atención el comentario de uno de los alumnos que exclamó ante el resort obtenido "¡Me esperaba algo más sencillo, no hubiera pensado que construiríamos algo tan bonito!". Justamente este el resultado de convivir con la incertidumbre consustancial y construir con Scrum: al principio no sabemos el producto que vamos a obtener, pero el marco garantiza que va a ser el mejor producto posible dentro del presupuesto y tiempo asignados.
Algunos resorts hechos con la simulación tienen auténticas joyas :-) Gracias a todos los alumnos que han participado con sus ideas y creatividad, que es impresionante, y una y otra vez no deja de sorprenderme