Conocí Scrum hace muy poco, a mediados del 2019, cuando por fortuna fui invitado a tomar un curso con Jorge Abad. Desde entonces he estudiado y aprendido bajo la guía de Juan Andrés Ochoa, Felipe Mejía y con el apoyo de Jorge en caso de cualquier duda.
El año pasado (2020) me certifiqué como Scrum Master con Scrum.org y no pasó mucho tiempo para que se presentara la oportunidad de utilizar lo aprendido en un proyecto real.
La aproximación
Afortunadamente para mi, la guía Scrum 2020 comienza diciendo: “Scrum se basa en el empirismo y el pensamiento Lean” porque realmente nada te prepara para afrontar el uso de Scrum en un proyecto real. Debes aprenderlo y entender que no hay una fórmula mágica sino que cada caso es único. Del papel al mundo real existe un trecho gigante y esto hace mucho más interesante (y a veces frustrante) su implementación. No en vano dicen que Scrum es fácil de entender y difícil de implementar.
Como buen aprendiz, meto la pata cuantas veces puedo, desde mi punto de vista, así es como aprendemos los humanos: fallando repetidamente hasta lograrlo.
Aplicar Scrum en Latinoamérica
Mi encuentro con la realidad, al menos en todas las iniciativas en las que he participado, ha sido con estas características:
- El equipo de Developers no es de diez o menos personas, o de entre tres y nueve personas. Es de una o dos personas.
- El tiempo de dedicación del equipo de Developers no siempre es del 100%.
- En algunos casos el equipo de Developers cambia frecuentemente, llegan y se van personas.
- En el presente, se hace difícil que estemos todos en un mismo espacio físico por lo que todos los eventos han sido de forma remota.
La aproximación que mejor me ha funcionado hasta el momento, y aquí me expongo intencionalmente a que me digan que lo que hago no es Scrum, es la siguiente:
1. Sugiero la estimación, en cada Sprint, como si fuera el primero. Se toma en cuenta lo logrado en el Sprint anterior pero no cuántos puntos.
La inspiración, y como busco que hagamos la estimación vino de este genial video de Jorge Abad:
http://www.lecciones-aprendidas.info/2020/10/Como-Estimar-la-Capacidad-Velocidad-de-tu-Equipo-Scrum-en-el-Primer-Sprint.html
Esta es la forma en la que buscamos hacerlo:
1.1) Se usa la escala 1, 2, 3, 5, 8, 13, 20, 40 y 100.
1.2) Los Developers buscan el o los Backlog items que consideran más sencillos y le colocan el valor 1 (pivote). Se busca asignar el valor pivote a los Backlog items de esfuerzo similar.
1.3) En relación a esos 1, se asignan valores de la escala al resto de los Backlog items del Product Backlog.
1.4) Los Developers indican el tiempo, en horas, que ellos consideran que toma hacer un 1.
1.5) Se hace el cálculo en días dividiendo el tiempo en horas que toma un 1 entre las horas laborales del día (yo uso 6 horas pero funciona con cualquier número). Con esto obtenemos el número de días-persona que toma completar un 1.
1.6) Si un 1 toma más de un día-persona, se solicita al Product Owner la división de los elementos con una estimación mayor a 3. mi sugerencia, por comodidad, es que el tamaño máximo sea de entre 3 y 5 puntos.
1.7) Se usan Sprints de dos semanas (10 días hábiles) y se asume que dos días se van en reuniones por lo que calculamos sobre ocho días hábiles.
1.8) Los Developers indican el tiempo, en días, que pueden dedicarle al Sprint. Ejemplo: 4 días (50%), 6 días (75%), etc.
1.9) La sumatoria de días de los Developers nos da el número de días-persona.
1.10) La división del total de días-persona (punto 1.9) entre el número de días-persona que toma terminar un 1 (punto 1.5) indica el máximo aproximado de puntos totales que pueden ser logrados en el Sprint.
1.11) Con base en el máximo aproximado de puntos, los Developers seleccionan los Backlog items a colocar en el Sprint backlog, el compromiso para el Sprint.
1.12) Los Developers dividen los elementos del en Sprint backlog tareas y colocan, en horas, el tiempo que puede tomar cada una de ellas. Mi recomendación es que una tarea tenga como máximo una duración de 6 horas (un día), de forma tal que cada día se pueda apreciar el avance en el tablero (Usamos Yodiz como herramienta).
Es importante tomar en cuenta que el pivote (elementos con valor 1 de esfuerzo) de este Sprint pueden ser muy diferentes a los del anterior o del siguiente. Esto es porque hay adiciones y cambios en el Product Backlog de acuerdo al criterio del Product Owner y los Stakeholders. También porque el equipo va siendo cada vez más consciente y conocedor del producto y va mejorando cada vez más la forma en la que trabaja.
2. Durante el Sprint, mantengo la interacción con el equipo de Developers de una forma similar a la idea que tengo sobre ser padre: Estar presente sin estorbar. Mantenemos canales en Telegram y Discord para la comunicación.
3. He encontrado que, al ser equipos tan pequeños y en Sprints tan cortos, los eventos son muy rápidos y, hasta el momento, han tenido en promedio estas duraciones:
3.1) Sprint Planning: 2 horas
3.2) Daily Scrum: 10~15 min
3.3) Sprint Review: 45 min
3.4) Sprint Retrospective: 30~45 min
4. En cada evento, y debido al componente remoto, usamos Miro y Google Meet como herramientas de trabajo.
El resultado ha sido muy positivo, tanto para los clientes como para los equipos. Los clientes han visto cómo poco a poco se convierte su iniciativa en realidad y los equipos agradecen constantemente la libertad que tienen para trabajar.
Los pasos siguientes en la aplicación de Scrum
En Castor la cultura es de aprendizaje constante y uso de lo aprendido, de experimentación. Por esa razón es que los pasos siguientes son:
- Buscar la simplificación del proceso de implementación (aplicando el principio Lean de eliminación de desperdicios)
- Adecuar el marco Scrum a cada iniciativa según las necesidades que se presenten, de modo tal que la generación de valor para el cliente y de bienestar para el equipo ocurra de forma incremental.
- Entender que lo que ha funcionado hasta el momento, puede no funcionar en la siguiente iniciativa.
La imagen de portada fue tomada de: Technology vector created by vectorjuice – www.freepik.com
Mantente al tanto de nuestras publicaciones a través de nuestras redes sociales: LinkedIn, Instagram y Twitter.
