Antes de comenzar, quiero mencionar que he leído muchas preguntas similares en este sitio sobre equipos ágiles donde algunos miembros trabajan a tiempo parcial, pero no he encontrado nada sobre cómo implementar ágil/scrum para un equipo. donde todo el mundo es de medio tiempo.
Comenzaré con algunos antecedentes sobre el proyecto y el equipo. Actualmente estoy trabajando en un juego de cartas coleccionables en línea similar a Magic the Gathering o Hearthstone. Este es un proyecto nuevo y administraré un equipo de 4 a 6 desarrolladores. Todos los desarrolladores van a la escuela o tienen trabajos de tiempo completo, pero todos acordaron pasar 10 horas a la semana trabajando en este proyecto. Todos vivimos en diferentes estados, por lo que todos trabajarán de forma remota.
Creo que un marco ágil (particularmente scrum) sería beneficioso para este proyecto, pero estoy buscando algunos consejos sobre cómo implementarlo. En mi oficina tenemos prácticas de scrum bastante "estándar" con sprints de 2 semanas, stand-ups diarios, planificación de sprints, preparación, retro, etc. Así que estoy buscando algunos consejos sobre cómo implementar scrum para este equipo (o algunas razones por qué no debería, si crees que es una mala idea).
Algunas preguntas particulares que tengo son:
Quiero que este proyecto sea agradable para todos, así que no quiero imponer grandes restricciones a todos. Pero, al mismo tiempo, quiero suficiente estructura para que tengamos éxito y estemos enfocados en la tarea. Cualquier sugerencia o idea sobre cómo implementar scrum para este equipo sería muy apreciada.
Formo parte de un equipo mayoritariamente remoto; y aunque no a tiempo parcial, mi último proyecto involucró a un equipo completo de empleados matriculados con disponibilidad a tiempo parcial para este proyecto/equipo. Espero que algo de mi experiencia le ayude a medida que resuelve las preguntas clave que ha enumerado.
- ¿Deberíamos tratar de establecer horarios en los que todos deberían trabajar, o deberíamos permitir que todos elijan sus horarios/trabajo cuando puedan?
Todos deben trabajar a su propio ritmo con hitos clave y entregables dentro del sprint/iteración.
- Parece que un stand-up diario no tiene sentido, especialmente porque las personas pueden estar trabajando en diferentes días y en diferentes momentos. ¿Tiene sentido tener tal vez 3 stand-ups en momentos específicos?
Fuimos a dos stand-ups a la semana y también usamos métodos no tradicionales como #slack para tener sincronizaciones y artículos de estacionamiento. También recomiendo encarecidamente LLAMA de Megan Torrance, ya que analiza un sistema que se parece mucho a un enfoque de metodología ágil para comenzar a comprender las formas de variar el enfoque.
- ¿Tiene sentido tener un sprint de dos semanas, o tendría más sentido un sprint un poco más largo debido a nuestras horas reducidas?
Sigo pensando que los sprints de dos semanas son necesarios; solo tenga expectativas lógicas de lo que se puede lograr en cada sprint.
He usado Scrum en varios equipos a tiempo parcial y la verdad es que nada cambia realmente: solo tienes una capacidad más baja, por lo que planificas menos trabajo en tus sprints.
Solo hay dos cosas que consideraría de manera diferente:
1) Tienes una cuarta parte del tiempo, así que espero que las reuniones sean una cuarta parte del tiempo. En un sprint de 2 semanas, en lugar de una planificación de 4 horas, buscaría terminarlo en una hora o menos. Esperaría que el Daily Scrum fuera más corto y, dependiendo de la disponibilidad, tal vez no diario. El único que podría no escalar es el retro porque puede ser difícil tener un retro efectivo en mucho menos de 30 a 45 minutos.
2) Puede ser un desafío para los miembros del equipo apoyarse mutuamente durante un sprint y puede ser tentador trabajar en silos para que las personas no se necesiten entre sí. Con una visión a largo plazo, generalmente hay muchos beneficios al superar esos desafíos y encontrar una manera de trabajar juntos.
Recomendaría centrarse en los principios ágiles sobre los marcos (Scrum en este caso). GitLab es una organización completamente remota y no adopta ningún marco específico, sino que prioriza los principios ágiles por encima de cualquier marco específico.
Si todos los que trabajan en el proyecto son remotos, los horarios de trabajo estrictos y las reuniones/ceremonias probablemente inhibirán los principios de Agile.
Alakazooom