scrum master

¡Pasamos tanto tiempo en reuniones que no consigo escribir código! ¿Demasiadas reuniones? ¿Cuánto tiempo debería dedicar oficialmente un desarrollador a las reuniones? La Guía de Scrum es bastante explícita sobre los eventos de Scrum, pero es posible que los totales no sean evidentes de inmediato. Partiremos del supuesto de que trabajamos 8 horas al día, 5 días a la semana: En definitiva. Tiempo dedicado a los eventos de Scrum Evento Horas/Sprint de 4 semanas horas al día % Horas Totales por semana Daily Scrum   0:15   2:15 Sprint Planning 8:00     2:00 Sprint Review 4:00     1:00 Sprint Retrospective 3:00     4:00 Refinamiento Backlog     10%         Total tiempo dedicado 10:00 En total, en una semana la dedicación estimada es de 10 horas a los eventos de Scrum. Esto es el 25% del tiempo disponible. Suena como mucho, ¿verdad? Quizás hay algunas cosas a tener en cuenta. El refinamiento de Backlog no es una reunión El refinamiento del Backlog no es en realidad un evento en el sentido estricto de la palabra. Es una variedad de actividades que realiza a lo largo del Sprint con un propósito: comprender el trabajo que tenemos por delante. El refinamiento del Backlog no tiene por qué ser una reunión de 4 horas con todo el equipo cada semana. Una sesión de mapeo de ejemplo puede contar como refinamiento de la Pila tanto como una charla informal con el Product Owner durante el café de la mañana sobre alguna idea que tengan para una nueva función. Dediquemos el tiempo que se necesite hasta este máximo Los tiempos mencionados anteriormente son los que la Guía Scrum considera la cantidad máxima de tiempo. No vayamos más allá de esto. De hecho, puede haber razones para dedicar menos tiempo: Nuestro equipo es pequeño. La alineación y el acuerdo nos llevan poco tiempo. Nuestro trabajo es más una cuestión de volumen que de complejidad y requiere poco esfuerzo para comprenderlo completamente. Nuestro equipo está familiarizado con el tipo de trabajo que realizamos. La experiencia en la materia es un bien común. Nuestro equipo está familiarizado entre sí y puede discutir problemas rápidamente y alinearse en soluciones. Nuestro equipo ha demostrado ser capaz de completar los detalles durante la implementación. Tengamos fe en nuestra capacidad para resolver las cosas a medida que avanzamos. También debemos tener en cuenta: el refinamiento del backlog no es el momento para un análisis técnico profundo. Si sabemos lo suficiente sobre el qué y el por qué, continuemos; la Planificación del Sprint y el Sprint en sí serán cuando entremos en el Cómo. Nuestro equipo se comunica continuamente. No es necesario tener una reunión explícita para comunicarnos. Nuestro equipo llega a las reuniones bien preparado. No puedo enfatizar esto lo suficiente: nada mata más la motivación que asistir a las reuniones sin estar preparados o sorprenderse mutuamente con elementos que podrían haberse abordado o anunciado antes. Si nuestra reunión tiene una agenda y la hemos trabajado: no lo tratemos. No es necesario que se traten temas solo porque se le asignó un tiempo en la agenda. Trabajando a tiempo parcial Si trabajamos a tiempo parcial, las 10 horas antes mencionadas significarán un porcentaje relativamente mayor de nuestro tiempo. Daily Scrum, Sprint Planning, Sprint Review y Sprint Retrospective son eventos que llevan la misma cantidad de tiempo ya sea que trabajemos 24, 32, 36 o 40 horas a la semana. En cuanto al refinamiento del Backlog: generalmente no consume más del 10% de la capacidad del Equipo de Desarrollo. Y como se hemos comentado, no tiene por qué ser una reunión de un gran equipo. Evitemos las interrupciones Profundizar en un problema, pensar en cómo resolverlo y luego implementarlo son actividades que generalmente se benefician de una atención ininterrumpida. Esto sugiere que debemos planificar las reuniones de tal manera que esto sea posible. Otra forma de interrupción es la reunión ad hoc. Tomar un descanso para dejar que nuestra mente funcione es una gran idea. No es lo mismo que tener que dejar el trabajo en cualquier momento. Si nuestro equipo tiene que lidiar con tales interrupciones, veamos si podemos nombrar a alguien diaria o semanalmente para que sea el primero en ser interrumpido para que otros miembros del equipo puedan concentrarse. Hora del día Averigüemos a qué hora del día funcionamos mejor para que todos tengamos una reunión. La hora exacta del día es diferente de una persona a otra. Llevemos un registro de cuándo es más productivo al implementar soluciones y planifiquemos reuniones en torno a eso. La estructura es importante, pero es posible que deseemos cambiar esta de vez en cuando. Probablemente no necesitemos esa otra reunión Antes de aceptar cualquier otro tipo de reunión que no sea un Evento Scrum, especialmente las recurrentes para todo nuestro equipo, preguntémonos si todavía no hay un Evento Scrum para ello. La Dirección quiere saber lo que está haciendo. Recordemos la transparencia, apertura e inspección de los Valores Scrum. Deberíamos querer compartir lo que sea que se esté haciendo. Disponer de elementos de comunicación de la información y estar dispuesto a explicarlo a quienes muestren interés. No necesitamos una reunión de equipo específica para esto. Dicho eso: Una necesidad de saber no es lo mismo que un problema de confianza. Los problemas de confianza y miedo entre el equipo y la dirección pueden obstaculizar el progreso y lo harán. Deben ser abordados y resueltos por el Equipo Scrum. El Scrum Master puede ayudar a identificar estos problemas. Nuestro equipo no debe temer que la dirección malinterprete o abuse de lo que nosotros hacemos transparente. Viceversa, no debería ser una tensión para el equipo producir información que satisfaga la curiosidad de la dirección. Debe ser información que se pueda crear fácilmente y que les resulte útil. ¿Los “stakeholders” quieren saber sobre la velocidad, los puntos de historia…? Como desarrolladores, no debemos sentirnos tentados a dedicar horas, puntos de historia u otras medidas de velocidad o de costes que

La Guía Scrum 2020 La Guía Scrum 2020 ya está disponible y se cambia para hacer que Scrum sea más accesible e inclusivo aparte de su uso casi exclusivo en el desarrollo de software. Podemos descargarnos de forma gratuita la nueva Scrum Guide 2020 y la Guia Scrum 2020 (ES) Principales cambios de la Scrum Guide 2020 En primer lugar, la nueva Guía es menos prescriptiva, eliminando muchas sugerencias como las preguntas estipuladas del Daily Scrum, al menos un elemento de acción obligatorio de la Retrospectiva que se convierte en parte del Sprint Backlog o el consejo sobre por qué las cancelaciones de Sprint son eventos raros. El Sprint Review pierde su receta detallada sobre cómo llevar a cabo el evento. Además, lo obvio ya no debe de comentarse: Scrum de hecho no es trivial de dominar. Curiosamente, los autores también eliminan otros elementos de la edición de la Guía Scrum 2017, por ejemplo, la magnitud del trabajo asignado al refinamiento del Product Backlog y al liderazgo de servicio. Aquí presentamos los diez cambios en la Guía Scrum 2020, sin ningún orden en particular, que se pueden considerar los más importantes: No más roles:  El equipo Scrum consta de un Scrum Master, un Product Owner y Desarrolladores. Dentro de un equipo Scrum, no hay sub-equipos ni jerarquías. Es una unidad cohesionada de profesionales centrados en un objetivo común, el objetivo del producto. (No hay más roles. Sin embargo, ahora hay responsabilidades). No hay más “Equipo de Desarrollo”: Los desarrolladores son las personas del Equipo Scrum que están comprometidas a crear cualquier aspecto de un Incremento de valor a utilizar en cada Sprint. El enfoque en el equipo Scrum: El equipo Scrum es responsable de todas las actividades relacionadas con el producto, desde la colaboración de las partes interesadas, la verificación, el mantenimiento, la operación, la experimentación, la investigación y el desarrollo, y cualquier otra cosa que pueda ser necesaria. Esta idea de equipo fortalecido también se refleja en el punto que el Equipo Scrum es ahora autogestionado y no autoorganizado. El liderazgo de servicio ya no se menciona: Los Scrum Masters son verdaderos líderes que sirven al Equipo Scrum y a la organización en general. Este cambio probablemente posicione el rol de Scrum Master más cerca de los Project Managers y Delivery Managers El objetivo del producto: El objetivo del producto describe un estado futuro del producto que puede servir como un objetivo para que el equipo Scrum planifique. […] El objetivo del producto es el objetivo a largo plazo del equipo Scrum. El concepto de “producto”: Un producto es un medio para ofrecer valor. Tiene un límite claro, partes interesadas conocidas, usuarios o clientes bien definidos. Un producto puede ser un servicio, un producto físico o algo más abstracto. Las revisiones de Sprint no son escapatorias: La revisión de Sprint nunca debe considerarse una escapatoria para liberar valor. Las liberaciones incrementales ya no son una prerrogativa del Product Owner: Si un elemento del Product Backlog no cumple con la Definición de Terminado, no se puede publicar ni presentar en la Revisión de Sprint. Compromisos: Cada artefacto contiene un compromiso para garantizar que proporcione información que mejore la transparencia y el enfoque frente al cual se pueda medir el progreso. (Ahora hay un lugar para el Sprint Goal, la Definición de Terminado, y el Product Goal mencionado anteriormente, ya que todos están vinculados a uno de los tres artefactos Scrum como compromisos). “Terminado” ahora crea un Incremento de Producto (potencialmente liberable): La Definición de Terminado es una descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto. En el momento en que un elemento de la Pila de Producto cumple con la Definición de Terminado, nace un Incremento. (Otra aclaración bienvenida: cuando el trabajo del Sprint Backlog cumple con el estándar de calidad del Scrum Team, constituye un Incremento liberable). Como se menciona, existen numerosos ajustes adicionales aquí y allá. Para mencionar algunos: los elementos del Product Backlog ya no se estiman, sino que se dimensionan, el Scrum Master ya no está eliminando impedimentos, pero ahora está causando la eliminación de impedimentos. Además, la pregunta ¿Por qué es valioso este Sprint? La pregunta se ha convertido en parte de la planificación del Sprint. Conclusión La Guía Scrum 2020 incluye cambios significativos en el marco para ampliar su atractivo a las aplicaciones más allá del desarrollo de software.