Hace unos días, y por los tiempos que corren, Jeff Sutherland (co-creador de Scrum) dio un webinar sobre equipos distribuidos, en el que hablaba sobre consejos y recomendaciones para estos días de trabajo en remoto.
La verdad es que prácticamente todo lo que cuentan en el vídeo lo hemos tratado en el blog, pero me pareció interesante sintetizarlo y ponerlo bajo el contexto del trabajo online.
Antes de seguir, puedes añadir este post a la serie que he estado escribiendo, estos días de aislamiento, sobre el trabajo en remoto:
- Retrospectivas online: 10 herramientas (5 de ellas de uso gratuito)
- Formación online, 4 opciones para estos días
- 6 consejos profesionales para salir reforzados del aislamiento por coronavirus (en vídeo)
- Agilidad en tiempos de teletrabajo (2): Recomendaciones generales para Plannings, Daily, Review y Retrospectivas
Las recomendaciones que dejaba el co-creador de Scrum (por cierto, aquí está el enlace a la entrevista que le hice hace años), a la hora de usar el framework Scrum con equipos que trabajan en remoto, distribuidos, de manera online, son las siguientes, que ya te decía que las hemos tratado casi todas:
1 – Equipos pequeños (o más pequeños de lo que ya deberían ser)
Una de las recomendaciones es trabajar con equipos pequeños (5 personas es lo recomendable), estables y dedicados. Hasta aquí esto aplicaría también si el trabajo no es remoto, ya sabíamos que el equipo en Scrum no debería ser de más de 9 personas, pero aquí el punto es reforzar la idea de que 9 ya es mucho.
Te dejo un post sobre este tema, que ya lo hemos tratado varias veces: Por qué los equipos con mucha gente (más de 7) son menos productivos y en el tamaño ideal de un equipo.
2 – Backlog en buen estado
Que el Backlog esté listo, teniendo cada equipo su Product Owner, que tiene priorizado, listo y claro el Backlog.
De nuevo, esto aplica siempre, pero en este caso, en el del trabajo en Scrum con equipos distribuidos, toma mayor importancia si cabe.
3 – Yesterday’s Weather
Yesterday’s Weather, o estimar en función de qué pasó en el último sprint, vendría a ser el patrón, la buena práctica típica, para realizar las estimaciones al principio del Sprint.
No repito más que todas estas prácticas aplican a trabajo en Scrum remoto y presencial. En este caso, la recomendación es prestar especial atención al Yesterday’s Weather como estrategia de estimación.
4 – Equipos multifuncionales, T-Skills y Swarming
Cuidar más aún si cabe el Swaming (el importante y desconocido Swarming, «flujo continuo de una sola pieza» o One-Piece Continuous Flow), es decir, centrarse en trabajar juntos en las historias de mayor prioridad, creando así, además, mayor conexión entre los miembros del equipo remoto, y reforzando las T-Skills.
5 – Buffer de interrupciones
No hace mucho te hable sobre esta práctica, en gestionando imprevistos en un Sprint (Illegitimus Non Interruptus).
6 – Tareas domesticas
Este es un viejo patrón de Scrum, que habla de no permitir que los defectos detectados estén sin tratar más de un día. Por aquello que hablamos de la generación de trabajo superfluo.
7 – Scrumming Scrum
El Scrumming Scrum es aplicar la mejora continua al propio Scrum.
8 – Métrica de la felicidad
Por aquello de que los equipos felices crean cosas de mayor calidad. Aquí la recomendación es, si cabe más en remoto, prestar atención a cómo va «el nivel de felicidad» de los equipos. Prácticas como los Niko Niko pueden aplicar aquí muy bien.
9 – Equipos juntos
Obviamente, en sentido figurado, en en sentido de trabajar en que el equipo se sienta que esté junto, que es uno.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Muchas gracias por el resumen.
La verdad es que todo del mundo agile, es bastante profundo.
Gracias por compartir