Páginas

miércoles, 25 de mayo de 2016

¿Cómo se puede experimentar para obtener un modelo de negocio de foma ágil?

Lienzo Business Model Canvas de Strategyzer
Si queremos experimentar con modelos de negocio sobre una idea que hayamos tenido a aplicar a un negocio nuevo o uno ya existente, podemos usar la herramienta que Alex Osterwalder diseñó ayudado por Yves Pigneur, el Business Model Canvas.

Se trata de un lienzo con distintos apartados interrelacionados que cubren todos los aspectos básicos de un negocio: segmentos de clientes, propuesta de valor, canales, relación con clientes, flujos de ingresos, recursos clave, actividades clave, asociaciones clave y estructura de costes.

La herramienta nos permite obtener de forma colaborativa elementos para cada uno de los aspectos. Obtenido el primer lienzo podemos ponerlo a prueba y experimentar, reflexionar sobre el planteamiento estratégico de cada uno de ellos, reflexionar y variar las relaciones que se producen entre ellos y extrapolar el impacto al modificar alguno de ellos, describir, discutir, diseñar, mejorar, retar, innovar, inventar, pivotar...

Para encontrar los elementos de los 9 aspectos que representan las áreas clave de una empresa, y que podemos estudiar en nuestro modelo de negocio, podemos responder a las siguientes preguntas:

Ejemplo de un Business Model Canvas de una hipotética
startup BilletesdeTrenFacil.com - cortesía de José Manuel Beas
Customer Segments (Segmentos de Clientes):
  • ¿Cuales son nuestros segmentos de clientes más importantes?
  • ¿Nos dirigimos hacia el gran público o a un nicho muy concreto?
  • ¿Hay segmentos de clientes interrelacionados?
  • ¿Quién es nuestro cliente más importante?
Value Proposition (Propuesta de Valor):
  • ¿Qué problema solucionamos a nuestros clientes?
  • ¿cómo damos respuesta a esos problemas con los productos o servicios de nuestra empresa?
  • ¿Cuál es nuestra estrategia competitiva?
Channels (Canales):
  • ¿Cómo vamos a entregar nuestra propuesta de valor a cada segmento de clientes?
  • ¿Qué canales funcionan mejor?
  • ¿Cómo pueden ser integrados en los procesos de nuestros clientes?
Customer Relationships (Relación con clientes):
  • ¿Qué relación esperan nuestros clientes objetivo?
  • ¿Qué va a inspirar nuestra marca en ellos?
  • ¿Cómo se puede integrarla en el negocio en términos de costo y el formato?
Revenue Streams (Flujos de Ingresos):
  • ¿Por qué valores nuestros clientes están dispuestos a pagar?
  • ¿Qué y cómo pagan?
  • ¿Cómo contribuye cada flujo de ingresos a los ingresos totales?
Key Resources (Recursos Clave):
  • ¿Qué recursos clave requiere nuestra propuesta de valor?
  • ¿Qué recursos son importantes en la mayoría de los canales de distribución, relaciones con los clientes, flujo de ingresos, ...?
Key Activities (Actividades Clave):
  • ¿Qué actividades clave internas son necesarias para poder entregar la propuesta de valor?
  • ¿Qué actividades son importantes en la mayoría de los canales de distribución, relaciones con los clientes, flujo de ingresos ...?
Key Partnerships (Asociaciones clave):
  • ¿Cuáles son nuestros socios y proveedores clave?
  • ¿Cuáles son las motivaciones para las asociaciones?
Cost Structure (Estructura de Costes):
  • ¿Cuáles son los mayores costes de nuestro negocio?
  • ¿Qué recursos y actividades clave son los más caros?
Una vez tengamos nuestro modelo de negocio ponemos iniciar nuestro proyecto, crear un contexto compartido mediante la incepción ágil, identificar nuestros procesos de negocio y crear una hoja de ruta para dar solución a nuestras necesidades mediante un User Story Mapping y su planificación de release correspondiente.

Para quién esté interesado en una herramienta on-line para experimentar un lienzo le invito a probar el Business Model canvas de Canvanizer.

jueves, 19 de mayo de 2016

¿Cómo medir el grado de adopción de Scrum de un equipo ágil?

Cortesía de freedigitalphotos.net
Para dar respuesta y encontrar el grado de adopción de un equipo ágil, Nicolás Escobar ha elaborado este Checklist de Scrum (el link lleva a un formulario de google drive con el cheklist) encuesta creada por @Autentia y que muestro en este post.

Este checklist representa una serie de preguntas que cualquier equipo de desarrollo ágil puede plantearse, tanto en el arranque de un proyecto basado en Scrum como en cualquier fase de construcción de un producto, para comprobar su grado de adopción al marco de trabajo.

El grado de adopción será la cantidad de checks cumplidos sobre 65, por encima de un 80% podemos obtener un grado que aporte beneficios en la productividad del equipo y no haber caído en un ScrumBut, pero hemos de recordar que sólo podemos afirmar que trabajamos con Scrum con un grado del 100%.

El checklist se divide en dos secciones: cuestiones sobre aspectos generales y preguntas a tener en cuenta en cada una de las fases del ciclo de Scrum.

ASPECTOS GENERALES

A. PREGUNTAS MÁS IMPORTANTES
Esta parte de checklist es la más importante y a la vez un resumen del resto. La teoría es que si respondemos positivamente a las siguientes cuestiones el resto perderían importancia.

☐ A.1. Entregamos software funcionando y probado cada 4 semanas o menos.
☐ A.1.1. Cada entrega se realiza en un entorno controlado o al que puede acceder el cliente.
☐ A.1.2. Se llevan a cabo liberaciones de versiones antes de cada entrega.
☐ A.2. Entregamos primero lo que aporta más valor de negocio.
☐ A.2.1. Está involucrado el Propietario del Producto en el proceso de priorización de las historias de usuario.
☐ A.3. El proceso de desarrollo se está mejorando continuamente.

B. EN RELACIÓN A LA FIGURA DEL PROPIETARIO DEL PRODUCTO

☐ B.1. El Propietario del Producto está claramente definido.
☐ B.1.1. Tiene la potestad para priorizar.
☐ B.1.2. Tiene el conocimiento para priorizar.
☐ B.1.3. Tiene contacto directo con el equipo y resuelve sus dudas.
☐ B.1.4. Tiene contacto directo con los interesados (clientes finales) y les traslada las dudas que no sabe resolver por sí solo.

C. EN RELACIÓN A LA FIGURA DEL SCRUM MASTER

☐ C.1. Existe un Scrum Master bien definido.
☐ C.2. El Scrum Master está accesible por todos los miembros del equipo.
☐ C.3. El Scrum Master tiene una estrategia para solucionar los impedimentos del equipo.
☐ C.4. El Scrum Master puede escalar fácilmente los impedimentos que no puede solucionar.

D. EN RELACIÓN A LAS ITERACIONES

☐ D.1. No exceden de la duración predefinida.
☐ D.2. El equipo no es interrumpido por agentes externos.
☐ D.3. El equipo generalmente entrega lo que se compromete a hacer.

E. EN RELACIÓN AL EQUIPO

☐ E.1. El equipo tiene las habilidades necesarias para desarrollar las tareas de las historias de usuario del sprint.
☐ E.2. El equipo puede dedicar tiempo a formarse.
☐ E.3. El equipo ve como positiva la metodología y además se divierte siguiéndola.
☐ E.4. Se trabajan 8 horas al día (o el límite de la jornada) y los sobreesfuerzos son voluntarios.
☐ E.5. Se discute, se critica y se experimenta con la metodología.

CICLO DE SCRUM

1. PRODUCT BACKLOG
Se mantiene a lo largo de todo el proyecto con todas las historias de usuario.

☐ 1.1. Están definidas todas las historias, incluidos los epics.
☐ 1.2. Las historias están escritas por el Propietario del Producto o en su lenguaje.
☐ 1.3. El equipo tiene acceso a toda la documentación sobre las mismas y está centralizado en la herramienta de gestión del proyecto.
☐ 1.4. Se ha realizado una estimación de todas las historias del backlog, en la que ha participado todo el equipo.
☐ 1.5. Se actualiza la información después de cada sprint (en función de la velocidad y la estimación dada, la fecha de release de una versión del backlog puede variar).
☐ 1.6. Es de propiedad exclusiva del equipo o hay historias que pertenecen a otros equipos de desarrollo.
☐ 1.7. El Propietario del Producto sabe explicar la motivación de cada historia de usuario para poder priorizarlas.
☐ 1.8. Está priorizado conforme al valor de negocio de cada historia.
☐ 1.9. Las historias tienen una estimación tal que es posible implementarlas en el ámbito de un sprint.

2. SPRINT PLANNING
Se lleva a cabo en el arranque de cada sprint.

☐ 2.1. El equipo completo participa junto con el Propietario del Producto.
☐ 2.2. El Propietario del Producto viene a la reunión de planificación con el listado de historias de usuario priorizadas para el siguiente sprint.
☐ 2.3. El Propietario del Producto ha comunicado con anterioridad el listado priorizado de las historias del siguiente sprint al equipo para que puedan prepararse mínimamente la reunión de planificación.
☐ 2.4. El equipo lleva a cabo una división de las historias en tareas técnicas.
☐ 2.5. Para cada historia se define un DONE, qué entendemos para dar como finalizada una historia, esto es, cuáles son los casos de prueba de la misma.
☐ 2.6. El equipo viene a la reunión con las cartas para estimar.
☐ 2.7. El equipo realiza una nueva estimación de todas las historias.
☐ 2.8. Se estima con una medida relativa de puntos de historia en vez de en tiempo.
☐ 2.9. Por orden, se designa a un miembro del equipo como responsable de preparar la demostración del sprint que estamos planificando.
☐ 2.10. Tras la reunión se actualiza tanto el panel físico como la herramienta de gestión del proyecto con la información actualizada resultado de la reunión de planificación.
☐ 2.11. Tras la reunión se genera el gráfico de burndown recogiendo el total de puntos de historia que incluye el sprint.

3. DAILY MEETING
Ocurre todos los días a una hora prefijada.

☐ 3.1. Ocurre todos los días y participa todo el equipo.
☐ 3.2. No dura más de 15 minutos.
☐ 3.3. Se realiza de pie frente al panel.
☐ 3.4. Cada miembro del equipo habla de lo que ha hecho desde el último daily meeting y de lo que va a hacer hasta el siguiente (hay una estimación de tiempos) señalando las tareas en el panel con las que ha trabajado y va a trabajar.
☐ 3.5. Cada miembro del equipo expone los impedimentos que ha tenido para desarrollar sus tareas con el resto del equipo.
☐ 3.6. Cada miembro del equipo, en caso de estar implementando una tarea, ha validado antes el diseño de la misma con otro miembro del equipo.
☐ 3.7. Cada miembro del equipo, en caso de haber terminado una tarea, le ha demostrado que funciona conforme al DONE de la tarea a otro miembro del equipo.
☐ 3.8. Cada miembro del equipo firma la tarea con la que está para hacerla suya.
☐ 3.9. Cada miembro del equipo sabe lo que los demás están haciendo.
☐ 3.10. El Propietario del Producto participa de la reunión al menos un par de días por semana.
☐ 3.11. Existe un gráfico de burndown que se actualiza diariamente.

4. DEMO
Se realiza al finalizar el sprint para demostrar que se han implementado todas las historias del sprint.

☐ 4.1. El responsable de la demostración prepara una presentación o una guía en la que se documenta qué historias se van a probar y qué pruebas se van a realizar de cada una de ellas.
☐ 4.2. Se realiza en un entorno controlado por el cliente o accesible al mismo y no en un equipo local de desarrollo.
☐ 4.3. Se realiza una demostración al Propietario del Producto de todas las historias aceptadas conforme a su DONE en el sprint.
☐ 4.4. Recibimos retroalimentación del Propietario del Producto sobre el resultado de las implementaciones.

5. RETROSPECTIVA
Se realiza al finalizar el sprint después de la demostración al cliente.

☐ 5.1. Ocurre al final de cada sprint.
☐ 5.2. El Scrum Master documenta el gráfico de burndown y actualiza qué velocidad media tiene el equipo. Adicionalmente documenta qué historias han formado parte del presente sprint y qué impedimentos han surgido en la consecución del mismo.
☐ 5.3. Se utilizan técnicas de retrospectiva para fomentar la participación de todos los miembros del equipo.
☐ 5.4. El resultado de la retrospectiva son propuestas concretas de mejora del proceso y la metodología.
☐ 5.5. El resultado de la retrospectiva se documenta en la herramienta de gestión del proyecto.
☐ 5.6. Se inspeccionan las propuestas de retrospectivas anteriores para ver las que han implementado realmente.
☐ 5.7. Participa todo el equipo incluido el Propietario del Producto.

Quiero agradecer a Nicolás Escobar el que comparta su Checklist de Scrum con quién tenga interés, gracias :-D

martes, 17 de mayo de 2016

¿Qué informaciones son necesarias y cuáles son opcionales en una historia de usuario?

Para decidir qué información incluir en una historia de usuario es preferible no adoptar formatos rígidos. Los resultados de Scrum y Agilidad no dependen de las formas, sino de la institucionalización de sus principios y la implementación adecuada a las características de la empresa y del proyecto. Por tanto, aparte de 3 campos que se consideran necesarios, se puede incluir cualquier campo que proporcione información útil para el proyecto, recordemos que el foco de las historias de usuario y sus informaciones es la construcción de un entendimiento compartido.
Ejemplo de una tarjeta de historia de usuario
Los campos que se consideran más necesarios para describir de una manera adecuada las historias de usuario son:
  • Descripción: descripción sintetizada de la historia de usuario. El estilo puede ser libre, según mejor nos funcione, debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se quiere? y ¿Cuál es el beneficio? Mike Cohn recomienda seguir el siguiente patrón que garantiza que la funcionalidad está descrita a un alto nivel y de una manera no demasiado extensa:
Como [rol del usuario], quiero [objetivo], para poder [beneficio]
Dependiendo del tipo de proyecto, el funcionamiento del equipo y la organización, pueden ser aconsejables otros campos como:
  • ID: identificador de la historia de usuario, único para la funcionalidad o trabajo.
  • Titulo: titulo descriptivo de la historia de usuario.
  • Valor de negocio: valor (normalmente numérico) que aporta la historia de usuario al cliente o usuario. El objetivo del equipo es maximizar el valor y la satisfacción percibida por el cliente en cada sprint. Este campo servirá junto con la estimación para determinar la prioridad con el que las historias de usuario deben de ser implementadas.
  • Criterio de aceptación: pruebas de aceptación consensuadas con el cliente o usuario. Estas son las pruebas que guiarán al equipo a lo largo de la construcción y que el código deberá superar para dar como finalizada la implementación de la historia de usuario.
  • Requerimiento no funcional: cualidades generales y restricciones. como la usabilidad o la seguridad, que afectan aplicaciones y sistemas enteros, y por tanto a las historias de usuario individuales.
  • Definición de hecho: la definición de hecho o Definition of Done (DoD) incluye los criterios o actividades necesarias para dar por terminada una historia de usuario (desarrollada, probada, documentada...), que son las convenidas por el equipo y el Propietario del Producto.
  • Dependencias: una historia de usuario no debería ser dependiente de otra historia, pero en ocasiones es necesario mantener la relación. En este campo se indicarían los identificadores de otras historias de las que depende.
  • Persona asignada: en casos en que queramos sugerir la persona que pueda implementar la historia de usuario. Recordar que en Scrum es en último término el equipo autogestionado quién distribuye y por tanto asigna las tareas.
  • Sprint: puede ser útil para organización del Propietario del Producto incluir el número de sprint en el que previsiblemente se vaya a realizar la historia.
  • Riesgo: riesgo técnico o funcional asociado a la implementación de la historia de usuario.
  • Módulo: módulo del sistema o producto al que pertenece.
  • Observaciones: para enriquecer o aclarar la información o cualquier uso que pueda ser útil.
Mike Cohn comenta que si bien las historias de usuario son lo suficientemente flexibles como para describir la funcionalidad de la mayoría de los sistemas, no son apropiadas para todo. Si por cualquier razón, se necesita expresar alguna necesidad de una manera diferente a una historia de usuario, recomienda que se haga. Por ejemplo, la maquetación de pantallas se suele describir con pantallazos, por tanto esta es la mejor manera de transmitir el diseño que queramos darle a una aplicación.
Ejemplo una historia de usuario - cortesía de Scrum Manager y Gertudis
Ejemplo una historia de usuario - cortesía de Scrum Manager
Os quiero invitar a visitar el mapa mental sobre historias de usuario de mi compañero Nicolás, en él encontraréis todo lo necesario para escribir buenas historias de usuario.

domingo, 15 de mayo de 2016

¿Existe algún juego para diseñar una estructura de equipos?

Como parte del curso de Management 3.0 se encuentra el juego de los Meedlers que permite visualizar y discutir sobre estructuras organizacionales basadas en equipos.

El objetivo del juego es el de facilitar discusiones acerca de estructuras organizativas con varios equipos de trabajo trabajando en varios proyectos, y lo permite hacer de forma colaborativa, sacando provecho del conocimiento y perspectiva de las diferentes personas que participen en esos proyectos

Tal como se describe en la página original del juego de los Meedlers, sobre la que baso este post, las discusiones que suscita tienen varios efectos positivos:
  • Los participantes se ven obligados a trabajar con una estructura plana, propia de Agilidad, lo que significa que no pueden hacer crecer a la organización con una jerarquía, sino que deben de hacerlo como una red de valor.
  • Las limitaciones del juego indican claramente que hay que crear equipos (en lugar de tener personas trabajando en solitario), y que hay que limitar el tamaño de los mismos a menos de 10 miembros por equipo.
  • Este juego hace que sea más fácil para los directivos permitir a los empleados inventar sus propias estructuras de equipo, permitiendoles discutir sobre los beneficios y los riesgos, y el valor que los diferentes equipos puedan proporcionar entre si.
Ejemplos de dos estructuras: para un gran proyecto con tres equipos y para un equipo ágil clásico de Scrum
El juego tiene muy pocas reglas, sólo dos cosas a destacar:
  • Un equipo funcional solo puede estar compuesto de personas con la misma función o rol. Un equipo multifuncional debe de tener personas con los diferentes roles necesarios para el cometido del equipo.
  • Para visualizar la colaboración y la aportación de valor entre equipos, los costados de sus fichas de equipo se colocan de forma que se toquen.
Los jugadores pueden desviarse de las reglas y doblar las limitaciones en la forma que deseen. Se pueden agregan funciones adicionales a las estructuras y conectar las fichas de equipo de forma creativa. Todo está permitido siempre y cuando los jugadores puedan explicar cuáles son los beneficios y los riesgos de su aportación.

Para quién quiera diseñar su estructura de equipos mediante este juego puede descargar las plantillas de las fichas libre y gratuitamente.

sábado, 14 de mayo de 2016

¿Cómo gestionar preguntas a los equipos sin que se les interrumpa?

¿Cuantas veces llega un cliente, un jefe de proyecto o un gerente, se presenta al equipo y empieza a hacer preguntas sin cuestionarse si los interrumpe en sus tareas?
Tablero de preguntas por David Marti

Esta práctica es frecuente, y sin ser conscientes de ello, resulta hasta en una falta de respeto.

Mike, uno de mis profesores, me contó la historia de Olaf, un compañero finlandés. Siempre que hablaba con él por teléfono cruzaba la mirada con su compañero de mesa y le decía "Es muy seco y escueto, ¡A Olaf no le caemos bien!". Unos meses más tarde conoció a Olaf y resultó ser un tipo muy simpático, y aprendió que en Finlandia los niños aprenden a respetar el tiempo de los demás de manera que aprenden a medir sus palabras.

A un niño español no se le enseña a respetar el turno de palabra, en Finlandia cuando uno habla los demás están acostumbrados a escuchar, asimilar lo que le están diciendo y sólo después hacer la réplica. En una estructura empresarial ágil y horizontal, en la que todos somos iguales, se hace necesario actuar como en los países nórdicos, como en Finlandia en este ejemplo.

Asistí a un curso de Managment 3.0 donde vimos el tablero de preguntas, una de las prácticas recopiladas por Jürgen Apello que introducen la cultura del silencio y del respeto, a modo de la cultura finlandesa. Se trata de un tablero con una columna "To Do" para preguntas entrantes en la que cualquiera que tenga una cuestión para el equipo pueda colocar un post-it. En cuanto alguien del equipo quede libre o haga un descanso, se dirige al tablero, escoge una pregunta, la pone "In Progress" y trabaja la respuesta. En cuanto tenga la respuesta la anota en la parte trasera del post-it y lo pone en "Completed".

Con este simple tablero podemos no faltar al respeto y evitar interrumpir a nuestros compañeros, a la vez que obtener una respuesta bien elaborada y de la forma más correcta.

El sistema se puede refinar de muchas maneras, por ejemplo utilizando post-its de colores para marcar la urgencia de una cuestión, por ejemplo con un post-it rojo. En este caso el miembro del equipo menos afectado dejaría de hacer lo que esté haciendo y atendería la pregunta directamente, pero sin que el resto del equipo se viera interrumpido.

Mis agradecimientos a David Marti por todo lo que he aprendido de su curso.

domingo, 8 de mayo de 2016

¿Cómo relacionar las prácticas de Scrum con los valores y principios de Manifiesto Ágil?

Como escribe Kent Beck en su libro "Extreme Programming Explained":

Explicitar los valores es importante porque sin valores,
las prácticas rápidamente se vuelven rutina,
actividades realizadas como un fin en sí mismas
pero carentes de propósito y dirección

Cuando no comprendemos el trasfondo de las prácticas de Scrum (reuniones, artefactos y roles), nos es fácil introducir variaciones que pueden parecer de todo sentido común, pero que están impregnadas de la cultura empresarial actual, y en ese momento es cuando convertimos las prácticas en ScrumButs (ScrumPeros).

Para ser ágiles hemos de tomar nuestras decisiones con mentalidad ágil, un pensamiento alineado con los 4 valores del Manifiesto Ágil, valores que nos dan la visión de conjunto bajo los que movernos. Para aterrizar, el Manifiesto Ágil nos da los 12 principios que son directrices que nos guían en nuestras prácticas, principios que están en todas las prácticas de Scrum.

En uno de los cursos on-line de Scrum Manager, Gertrudis propuso hacer una actividad a través de la cual los participantes pudieran construir las relaciones entre las prácticas de Scrum y su base, el Manifiesto Ágil. La implementamos creando un mapa mental colaborativo en la herramienta Mindmeister, en donde colocamos los tres grupos de nodos a relacionar: valores y principios del Manifiesto Ágil y las prácticas de Scrum. Los participantes tenían que descubrir y dibujar las relaciones que veían entre los diferentes elementos y hacer una reflexión del porqué en el foro de discusión correspondiente. A continuación las imágenes de la evolución del mapa mental desde el principio hasta el final de la actividad.
El mapa mental al principio de la actividad
El mapa mental al final de la actividad con las conexiones establecidas por los alumnos
El éxito del ejercicio fue abrumador. Pensamos que se incrementó significativamente el nivel de participación por ser una actividad colaborativa, 45 posts en el foro, cuando el promedio de posts por actividad es de 15, un 33,3% más de participación. Creemos que entre las razones de estos resultados se encuentra el hecho de que los participantes podían compartir la experiencia de la construcción del conocimiento, y de un proyecto común, con sus compañeros, e interactuar en un entorno colaborativo de aprendizaje de manera simultánea, además de la curiosidad que despierta el tema y la dinámica en sí.

Poco después estuvimos aplicando el ejercicio en presencial. La idea fue utilizar el concepto de un árbol y como metáforas las raíces como valores, las ramas soportadas por las raíces como principios y los frutos colgando de las ramas como prácticas de Scrum.

Dividimos el ejercicio en dos partes, una primera después de entender el Manifiesto Ágil para afianzar las relaciones entre valores y principios, y posteriormente una segunda parte después de haber trabajado el marco de Scrum, para entonces poder relacionar las prácticas con los valores y principios.

El concepto del ejercicio es el siguiente:
Ensayo del árbol en un tablero
Material y preparación del árbol reutilizable
  1. Dibujar un árbol, 4 raíces (1), 12 ramas (2) y la copa
  2. En la raíces escribir los cuatro valores del Manifiesto Ágil (1)
  3. En las ramas escribir los 12 principios del Manifiesto Ágil (2)
  4. Primera parte del ejercicio: después de ver el Manifiesto los alumnos salen al tablero de forma rotativa y dibujan una línea (3) desde una raíz (1) a una rama (2). El alumno razona la relación que ha establecido y se debate cortamente en grupo. Se hace con timeboxing de por ejemplo de 30 minutos. Nota: algunos participantes también ven relaciones entre un valor y otro, o entre un principio y otro, lo cual es completamente válido.
  5. Segunda parte del ejercicio: después de ver el marco de Scrum los alumnos anotan reuniones, artefactos y roles en post-its que a modo de frutos cuelgan de la rama o intersecciones de ramas que evidencian los principios y valores subyacentes en las prácticas. Los alumnos lo hacen de forma rotativa, y una vez puesto una, el alumno que la ha puesto, razona la relación que ha establecido y se debate cortamente en grupo. Se hace con timeboxing de por ejemplo de 30 minutos.
Finalmente decidimos construir un árbol reutilizable, usando láminas de foam verde y marrón para hacer el árbol, y post-its de manzanas y flores para los frutos. Para no rayar el árbol pintando las relaciones con rotulador, pensamos en probar con cinta aislante de colores, y ¡¡¡funcionó!!!
El Árbol de completo de relaciones entre las prácticas de Scrum y el Manifiesto Ágil
Para los alumnos fue una experiencia muy amena y que los puso a pensar y a reflexionar, interiorizando el significado del Manifiesto Ágil como base de las prácticas de Scrum. Surgieron todas las relaciones importantes… y algunas no tan evidentes a primera vista. Al igual que en la actividad on-line, se podía evidenciar claramente la motivación que generaba la construcción colaborativa de conocimiento a través de un proyecto común, obteniéndose un nivel de sinergia inmenso que no se hubiese alcanzado al hacerlo de forma individual o inclusive por parejas.
Fotos del ejercicio en la clase presencial
Nuestro próximo experimento para los cursos presenciales donde haya un gran número de participantes y sea complicado hacer la dinámica a nivel global, consistirá en poner en práctica un juego de cartas con los mismos objetivos, relacionar las prácticas de Scrum con el Manifiesto Ágil. Ya os contaremos en un próximo post en qué consiste el juego y cómo nos ha resultado esta nueva dinámica.

Post escrito conjuntamente con Gertrudis López, link al post en su blog "Agile: lo bueno, lo feo y lo malo"

Desde Chile Ricardo nos envía estas fotos del ejercicio de su clase presencial de Scrum Manager:
Fotos del ejercicio en la clase de Ricardo - mis agradecimientos a Diacos Asesores