Scrum en clases de Formación Secundaria (ESO)

Anotaciones sobre una de las sesiones que tuvieron lugar en el encuentro de “Clases ágiles en
Educación Secundaria”, al que asistieron unos 50 profesores y contó con la imprescindible
aportación de Arno Delhij, uno de los creadores de EduScrum,

¿Por qué Scrum en la escuela?

Por que el aprendizaje tradicional, del siglo XX, basado en logros individuales, puede

mejorarse

1. En lugar de clases unidireccionales, es mejor si los alumnos tienen autonomía en su manera de

aprender y se incorpora diversión. Todo esto redunda en una mayor motivación en el aprendizaje.
2. Por que el mundo de la empresa está cambiando, de basarse en la individualidad hacia el trabajo
en equipos multidisciplinares.

El método funciona para proyectos o para asignaturas completas.

Roles:

 Product Owner: Profesor, da los objetivos de aprendizaje con criterios de aceptación, el QUÉ.
 Equipo: Los alumnos, identifican y hacen el CÓMO.
 Scrum Master: En el inicio el profesor asume también este rol (dado que los alumnos todavía no
conocen el proceso), aunque al cabo de un tiempo se puede llegar a crear el rol de Facilitador del
método (y de “creación” del trabajo en equipo) dentro de cada uno (ojo, no confundir con team
lead que decide qué trabajo es el que hay que hacer y lo divide en tareas para personas, eso sería
la antítesis de lo que estamos buscando, equipos auto-organizados con un facilitador que les ayuda
a pensar a todos juntos para obtener un resultado mejor). A las chicas se les suele dar muy bien
ese rol

Proceso:

Inicio:

 Equipos de 4 personas, con diversidad:

 Niños y niñas.
 Diferentes skills para poder realizar el proyecto.
 No amigos!
 Se pueden autoformar. Ejemplo:
 El profesor escribe 10 características que tiene que tener el equipo.
 Cada alumno escribe en un post-it las 3 que más le representan. Detrás escribe su nombre.
 Anónimamente se crean los equipos, de manera que se cubran al máximo todos los skills
necesarios.
 Los equipos permanecen estables durante el proyecto, o el cuatrimestre. Los niños pueden
pedir cambiar los equipos si justifican bien la razón (e.g. necesitan algún skill concreto).
 Las 2 o 3 primeras clases son para explicar el método a los niños.

Ciclos (Sprints):

 Duración:
  Por ejemplo de 8 semanas o un cuatrimestre (o lo que sea necesario).
 En el primer caso, si tuviésemos 3 clases por semana, un Sprint podría contener 18 clases
de trabajo real (8 semanas x 3 clases/ semana menos las de hacer el backlog y las de
review + retrospectiva). (*)
 Planificación:
 Los alumnos identifican las tareas (post-its).
 Estiman el trabajo de cada tarea, para ver si todo el trabajo les cabe en el Sprint. La
estimación es de manera relativa (lo más sencillo es utilizar tallas S, M, L) aunque
también se pueden utilizar puntos relativos.
 El resultado se pone en el tablero del equipo. De esta manera, en la clase se puede ver
cómo están avanzando todos los equipos simultáneamente.
 Una diferencia importante con el método tradicional (donde los contenidos se van
descubriendo de manera secuencial, página por página) es que les hace comenzar viendo
todo el Sprint (o toda la asignatura) con una perspectiva global.
 Stand-ups:
 5 minutos al empezar cada clase para que los alumnos actualicen el tablero.
 Diagrama de Burn-down:
 Permite que el equipo vea cómo va su progreso en el Sprint, si va retrasado (tienen que
“ponerse las pilas”) o avanzado (lo cual les motiva también para avanzar más).
 Puede ser sencillo (no hace falta contar puntos de complejidad de cada tarea/historia),
basta contar los postits que todavía no están acabados en el Sprint.
 Revisión:
 El equipo demuestra qué ha aprendido. Opciones:
 Pasar un test (opción “tradicional”).
 Hacer una “presentación”.
 Hacer un trabajo (documento).
 Identificar preguntas de test para el global de los alumnos de la clase.
 Retrospectiva:
 Qué les ha funcionado en ese Sprint / qué tienen que mejorar.
 Cada alumno también puede analizar si está aportando los skills que se suponía que
iba a traer al equipo.

 Y vuelta a empezar del ciclo

Sobre el rol del profesor

 El profesor intenta que los niños aprendan cómo hacer el trabajo de la manera más
autónoma (crear capacidad de aprendizaje). Un ejemplo sencillo: si hay alguna tarea (CÓMO)
que no se están dando cuenta que tendrían que identificar, en lugar de decírselo al equipo, por
ejemplo le puede sugerir que vayan a ver los tableros de otros niños, para que vean qué tipo de
tareas están generando y reflexionen sobre ello… o les deja que por ellos mismos descubran, al
cabo de unos días, que se den cuenta de que les faltaba esa tarea por identificar (lo cuál reforzará
su aprendizaje).
 El hecho de que los alumnos vayan trabajando en las tareas de manera autónoma, donde puede
haber momentos en que todos los equipos están trabajando en la clase, proporciona al profesor
un tiempo extra para poder ir a ver cómo trabaja cada equipo, solucionar problemas
específicos que esté teniendo, una atención más a medida.

Y una idea adicional: el aprendizaje es tanto mayor conforme tiene un propósito (por ejemplo un
proyecto) y si además ese proyecto es multidisciplinar (confluyen varias asignaturas), por ejemplo
¿cómo funciona un teléfono móvil? (matemáticas, física, química, sociales, …).
 (*) Este método de trabajo es más productivo que la clase tradicional, produce mejores resultados
de aprendizaje y además… hace crecer los soft skills de trabajo en equipo!!

Finalmente, y en línea con las ideas con que empieza este post, lo más importante no ha sido tanto
conocer el método si no ver que hay profesores realmente motivados en mejorar el sistema de
aprendizaje de los niños, para crear mejores personas en el futuro, más preparadas y con más
habilidades para tratar unas con otras, profesores que han dedicado su tiempo personal de un
sábado por la mañana para aprender y compartir. Muchas gracias a todos por este esfuerzo para
hacerlo real, y a la organización y ponentes por contribuir a este propósito.

Gestión ágil de proyectos con Activecollab, Googledocs y Yammer – VIII encuentro ágil
en Barcelona

En este encuentro Alexis Roqué explicó su ecosistema ágil. Se hizo hincapié en el ecosistema
como soporte a la comunicación entre los actores que participan en un proyecto (incluyendo al
cliente), en la necesidad de un jardinero del ecosistema (en función de su complejidad) y en lo
interesante que puede ser disponer de un buen sistema de gestión y push de conocimiento a nivel
de empresa. Finalmente se subrayó que un cambio en la manera de trabajar siempre implica
formación, perseguir e ir mejorando.

Objetivo de un ecosistema ágil

El objetivo de un ecosistema ágil es que todo fluya para poder

proporcionar resultados y productividad. Un ecosistema de herramientas da soporte a una
metodología determinada y a sus prácticas; en el caso de las metodologías ágiles, especialmente
es un soporte a la realización de tareas de manera eficiente basándose en la comunicación entre
todos los actores [1].

Por ello, el ecosistema ágil debe ser:

 Un canal de comunicación entre los miembros del equipo y también con el cliente.
 Un repositorio de información.
 Una agenda / planificador que permita monitorizar / hacer seguimiento.
 Accesible remotamente y a la vez tangible, que casi se pueda tocar físicamente.
 Aceptado por el equipo, que perciba su beneficio.
 Con la entrada de datos muy automatizada.
 Que facilite el aprendizaje del equipo, que vaya mejorando en su manera de trabajar [2].

La participación del cliente

La participación del cliente es especialmente importante cuando se trabaja con metodologías

ágiles. Por ello es importante considerar cómo este actor puede interactuar con él:

 Consultando el estado de los objetivos/requisitos, burndowns, e incluso creando los

objetivos/requisitos.
 Se puede asignar tareas al cliente como, por ejemplo, que suba al gestor de contenidos
información relevante del proyecto.
 El jardinero del ecosistema

Puede ser necesaria una figura que se encargue de mantener suficientemente pulcro el ecosistema,
especialmente es complejo por que existen muchos módulos, algunos sin integración automática.
Esta persona se encarga de:

 Estructurar la información.
 Quitar ruido.

Para reducir su labor al mínimo, es recomendable que existan procedimientos de trabajo con el
ecosistema y guías de uso de las herramientas.

Este jardinero del ecosistema, entre otras cosas, puede ser la misma persona que se encarga de
recoger las retrospectivas de cada proyecto y difundir sus conclusiones poniéndolas en un Wiki
global, o bien quien se encargue de avisar a quienes no están reportando las horas de trabajo
pendiente (que permiten crear el burndown).

Ejemplo de ecosistema ágil

En el encuentro se presentó el siguiente ecosistema:

Tipo de Herramienta Producto Observaciones

Content Management Server ActiveCollab Ficheros binarios (documentos,

imágenes)

Wiki ActiveCollab Versionado, comentarios, discusión,

etiquetas, búsquedas.

Sirve también como repositorio de

lecciones aprendidas.

Project Management ActiveCollab

Issue Management ActiveCollab

Software Configuration Management Subversion Está desligado de ActiveCollab. La

trazabilidad se mantiene de manera
manual.

Continuous Integration Server Maven

Communication Booster Gmail + GTalk

Twitter o Jammer

Demo / Preproduction Server

Sprint Backlog GoogleDocs Con burndowns.

ActiveCollab es fácil de desplegar (incluso existe el formato ASP). Da un buen resultado (Pareto
80/20). Sus principales problemas son:

 Wiki y calendario limitados.

 No dispone de una visión multiproyecto.
 Hay un Wiki por proyecto. Esto impide disponer de un repositorio de lecciones aprendidas (ni
gestión del conocimiento) para toda la organización si no es haciendo una copia manual de las
lecciones de cada proyecto hacia un Wiki corporativo.
 No es Open Source.
 No hay charting.
 No es un tablero de tareas físico, con lo que se pierden los efectos de radiador de información y
psicológico de ir moviendo las tareas a estado “hecho”.

Se propusieron otras herramientas, en función de la tecnología de desarrollo y el precio de las

herramientas: Redmine, Jira + Confluence + Greenhopper, Team Foundation Server (Microsoft).

Twitter / Jammer

 Se utiliza para toda la empresa, para solicitar ayuda (por ejemplo indicar en qué estás atascado)
y/o que fluya información de interés. Incluso se plantean incentivos para quien realice el mejor
post. El problema es que como gestor de conocimiento es limitado. Una alternativa es utilizar una
delicious como gestor de conocimiento con Twitter como push.
 Por otro lado, es muy necesario tener disciplina en lo que se escribe y no hacer ruido. Para ello
ayuda que los gestores y jefes de proyecto estén suscritos J
 NO se utiliza para comunicarse dentro de las tareas propias de un equipo. Los miembros del
equipo deben ser capaces de comunicarse de manera más directa, especialmente si están co-
localizados.
 Jammer dispone de un Niko Calendar. Dentro de la empresa se considera “obligado” empezar el
día indicando cual es tu estado de ánimo, para que si tienes algún problema otra persona se de
cuenta, pueda interesarse por ti y ayudarte.

Inconvenientes para la implantación de un sistema

Finalmente se mencionó que el principal inconveniente para la implantación de un sistema es,

como siempre, el cambio en la manera de trabajar, que implica formación en el sistema y
perseguir su uso. Una vez implantado, hay que ir mejorando el sistema.