ES 
EN 
JA 
IT 
La prueba de la técnica
Durante los últimos cinco años he tenido una carrera increíble como Scrum Master. No hago esa distinción porque antes no me gustaba ser Scrum Master, sino porque no era Scrum Master en absoluto… era profesor de Química. Solo recientemente observé estos dos roles y descubrí algunas similitudes clave (¡incluida una que los adolescentes y los desarrolladores de software no son tan diferentes como podría pensar!). Fui y sigo siendo un facilitador, un gestor, un eliminador de impedimentos y un agente de cambio. Entonces, me hizo pensar que, debido a que estos dos roles eran similares, ¿podrían volver a aplicarse algunas de las técnicas en un contexto diferente? Resulta que ¡absolutamente!
Quería escribir algunas técnicas que solía usar en un salón de clases de estudiantes y que ahora uso en una sala de reuniones de adultos. Cuando participé en la capacitación de personas para enseñar, 'Creatividad en el aula' era donde encontrarías mi nombre en la agenda de capacitación. Para mí, la capacitación no se trata de ideas conceptuales, sino de técnicas duras y rápidas que puedes aprender y aprovechar mañana. En eso me he centrado aquí. Es posible que tengan resultados a más largo plazo, pero las prácticas son fáciles y me han dado excelentes resultados. Tenga en cuenta que sé que incluyen prácticas complementarias a Scrum y que no existe un tema consistente.
Los estudiantes trabajan en parejas y retroalimentan para ayudar al resto del grupo -> Refinamiento por adelantado
Bueno para: acercar el equipo a los usuarios y desagregar el "comando central".
Antes de una sesión de Refinamiento del Backlog del Producto (o similar), solicite a los Desarrolladores que compartan uno o dos PBI del Backlog del Producto para refinarlos en pares. Pídales que interactúen con los usuarios finales, el propietario del producto y las partes interesadas relevantes para obtener transparencia en la "pregunta". La pareja escribe la descripción en colaboración con el propietario del producto y pueden agregar criterios de prueba o cualquier otra cosa relevante. En definitiva, necesitan tiempo para comprender los requisitos técnicos del PBI. Hacer esto por adelantado logra algunas cosas:
✔️ El conocimiento del próximo trabajo se comparte entre los desarrolladores. Todos los miembros se centran en ayudar al resto del equipo, por lo que se genera más una sensación de "un solo equipo".
✔️El tallaje es más suave. A menudo, los desarrolladores hacen numerosas preguntas técnicas al PO que descarrilan el propósito del refinamiento: la transparencia del valor. Si algunos de los desarrolladores ya han estado involucrados en detallar el PBI, pueden "evitar" las preguntas técnicas si no son relevantes.
✔️Estimar está más informado. Hay más confianza en la sala en que los pronósticos son confiables.
Compartir el objetivo de aprendizaje al comienzo de una unidad -> Visualizar un objetivo de Sprint
Bueno para: mostrar a todos cómo contribuyen al panorama general del Sprint.
Pega tu objetivo de Sprint en la parte superior. Ese es el objetivo y un único enfoque (¿alguna vez has oído hablar de una pirámide con dos picos?... no, una pirámide, un enfoque, un Sprint Goal).
Los PBI que son dependencias están en el nivel más bajo porque es necesario hacerlos primero. Son la base sobre la cual la validación de su Sprint Goal será exitosa o no. Sin la base, es muy poco probable que logres tu objetivo. Los PBI que se pueden realizar una vez que se han resuelto las dependencias son el siguiente nivel.
✔️La Pirámide muestra cómo cada PBI contribuye al panorama más amplio.
✔️ Fomenta la aceptación de todos los desarrolladores, incluso cuando están trabajando en algo "pequeño", porque pueden ver por qué cada PBI es importante.
✔️A las partes interesadas les encanta porque es visual.
✔️Puedes colorear triángulos durante el Daily Scrum para mostrar el progreso, o agregarlos o eliminarlos según sea necesario.
Es importante destacar que no se obsesione con que siga teniendo forma de pirámide. Es una estructura para apoyar una planificación transparente, ¡no sólo para crear una imagen bonita!
Resolución de comportamiento -> Miembro del equipo ficticio
Bueno para: Empatía y reenfoque de conflictos entre equipos.
Los equipos Scrum están formados por personas y, por lo tanto, las cosas pueden volverse emocionales. Probablemente todos hemos estado en una Retrospectiva de Sprint cuando las cosas se han desbordado y tal vez hayan cruzado la línea hacia lo "personal". Intente utilizar un miembro ficticio del equipo con una historia de fondo (el nuestro es un desarrollador llamado Jerry; es lógico y siempre justo). Si un conflicto se está saliendo de control, haga que el equipo se siente y piense cómo se sentiría Jerry.
✔️ Los participantes dejan de pensar en cómo se sienten y empiezan a considerar cómo se siente otra persona (empatía).
✔️ Elimina el aspecto personal del conflicto (desescalada) y muchas veces permite un camino a seguir.
Estas son sólo algunas de las cosas que he extraído directamente de mi repertorio docente y hay muchas más. Se centran en el empoderamiento sin apropiación, la igualdad a través del compromiso y el liderazgo desde dentro.
No he entrado en demasiados detalles porque no creo que sea necesario. Todos ustedes son practicantes con circunstancias únicas, así que tomen lo que quieran, prueben la Técnica de Prueba y, si no funciona, tírenlo. Seamos empíricos al respecto.