• Author / Uploaded
• TerrySantiago

• Categories
• Software
• Liderazgo
• Liderazgo y tutoría
• Ingeniería de software
• Business

Citation preview

Preguntas de entrevista para Scrum Masters Este documento contiene una traducción de las preguntas de entrevista para Scrum Masters, sugeridas por Stefan Wolpers y Andreea Tomoiaga1. Este recurso no se encuentra orientado solamente a los reclutadores de roles ágiles, sino también a todos los que nos encontramos en la práctica habitual de Scrum.

El rol de un Scrum Master Pregunta 01 El manifiesto ágil infiere “personas sobre los procesos”. Por lo tanto ¿No es el Scrum Master - cuyo rol está destinado a hacer cumplir el proceso - una contradicción? Un Scrum Master no ejerce ninguna autoridad real. El Equipo Scrum no le reporta. El objetivo de esta pregunta es ayudar a revelar si el candidato entiende que su función es liderar el equipo, en lugar de gestionarlo. Hacer esta pregunta también es probable que revele por qué el candidato está interesado en el rol de Scrum Master en primer lugar. Las respuestas aceptables deben enfatizar la facilitación y el apoyo: ● “Soy el facilitador del Equipo Scrum. Mi trabajo es hacerlos exitosos". ● “No soy ni project manager, tampoco gerente de RRHH. Apoyo al Equipo Scrum para lograr su autogestión. No le digo a las personas qué hacer". ● "Soy el facilitador del Equipo Scrum como instructor, coach o mentor, y los aliento a sobresalir como un equipo ágil". Pregunta 02 ¿Qué indicadores podrían existir para demostrar que las prácticas ágiles funcionan en la organización y cuáles de estos demostrarían que los esfuerzos en agile están teniendo éxito? No existe un estándar o definición general de "éxito ágil" que pueda usarse para medir la agilidad de una organización. Cada organización debe desarrollar sus propios criterios. La velocidad de equipo2 en crecimiento generalmente no se considera un indicador significativo (vea la pregunta 40 para una discusión de la velocidad de equipo). Sin embargo, aunque en su mayoría son indirectos, hay varios indicadores que pueden ser útiles para determinar el éxito: 1

38+9 Scrum Master Interview Questions to Avoid Agile Imposters [PDF and Video] https://age-of-product.com/38-scrum-master-interview-questions-to-avoid-imposters-free-pdf/ 2 La velocidad de equipo es una medida del trabajo completado dentro de un período de tiempo determinado en base a comparaciones relevantes.

@marcoviaweb

● ●

●

●

● ● ● ● ●

La mejora de la felicidad de un equipo se expresa mediante una reducción de la rotación y un aumento del número de referencias de los miembros. El incremento de la competitividad en la batalla por el talento se puede demostrar mediante el aumento en el número de personas con experiencia que desean unirse a la organización. Los productos entregados a los clientes se traducen en mayores índices de retención, mejores tasas de conversión, mayor duración del valor y mejoras similares para el negocio. El incremento de la calidad del software se puede demostrar con una considerablemente menor Deuda Técnica3, menos errores y menor tiempo dedicado al mantenimiento. El tiempo de producción, desde la validación de la idea hasta el envío del producto, se ha sido reducido. El Cycle Time4 para la validación de hipótesis se ha reducido. Se ha reducido la asignación de recursos a productos de bajo valor. Hay un mayor respeto entre los Stakeholders por el equipo de TI. Los Stakeholders participan cada vez más en reuniones ágiles, especialmente durante el Sprint Demo5.

Pregunta 03 ¿Debería un Scrum Master eliminar los impedimentos en nombre del Equipo Scrum? Un Scrum Master no debe preocuparse por "eliminar impedimentos en nombre del Equipo Scrum", sin importar con qué frecuencia se menciona este requisito en los anuncios de trabajo. Si un Scrum Master actúa como una "mamá de Scrum", su equipo nunca se auto-organizará. Un Equipo Scrum debe tomar sus propias decisiones. Esto resulta casi inevitablemente en fallas, callejones sin salida y otras excursiones no planificadas cuando el equipo está aprendiendo algo nuevo. En consecuencia, al principio, un equipo necesitará más orientación de lo habitual por parte del Scrum Master - y de una clase distinta al que se ejemplifica para dibujar tableros offline (ver Preguntas 31 y 32) o actualizar tickets en JIRA6. Sin embargo, dicha orientación no debe convertirse en un ejercicio de “sobre protección de hijos”: se debe permitir que un equipo aprenda de sus fracasos. Pregunta 04

3

La Deuda Técnica es el trabajo de desarrollo adicional que surge cuando se utiliza un código que es más fácil o más rápido de implementar a corto plazo en lugar de aplicar una mejor solución global. 4 Cycle time, es el número de días entre el inicio y el final de un experimento adecuado para validar o falsificar la hipótesis motivadora. 5 Parte del Sprint review, el Sprint Demo es el evento durante el cual el Equipo Scrum presenta el trabajo completado durante el Sprint a los stekaholders. 6 JIRA® es un sistema de software patentado publicado por Atlassian Pty Ltd. para la gestión de proyectos y seguimiento de issues.

@marcoviaweb

¿Cómo debe comunicarse un Scrum Master con el Product Owner? Comunicarse de manera honesta y abierta es la mejor manera para que un Scrum Master obtenga la cooperación del Product Owner. Ambos deben servir como líderes sin ser autoritarios, y cada uno depende de que el otro trabaje recíprocamente para el éxito de un Equipo Scrum (por ejemplo, lograr la meta de un Sprint). Son aliados con respecto al coaching de la organización para volverse, y seguir siendo, ágiles. El Product Owner es responsable de proporcionar una retroalimentación rápida sobre asuntos del producto, de aclarar los objetivos y de garantizar que todo el equipo de delivery del producto7 comprenda la visión. El Scrum Master, en cambio, apoya al Product Owner en la creación del Product Backlog de alto valor, y para este fin debe facilitar la colaboración efectiva entre el Product Owner y el Equipo Scrum. Pregunta 05 ¿Debería el Equipo Scrum involucrarse en el proceso de Product Discovery y, de ser así, cómo? Hay dos razones principales por las que un Equipo Scrum debería participar en el proceso de Product Discovery lo antes posible: 1. Cuanto antes participen los ingenieros en el proceso de Product Discovery, menores serán las posibilidades de buscar soluciones que técnicamente no sean viables o que no generen un retorno de la inversión. 2. Involucrar a un Equipo Scrum desde el principio garantiza que el equipo y el Product Owner desarrollen una comprensión y sentido de propiedad compartida de lo que se construirá. Esto ayuda significativamente con la asignación de recursos a los problemas correctos, maximizando el valor para el cliente y mitigando el riesgo de inversión. Involucrar a los ingenieros de un Equipo Scrum al inicio del proceso garantiza su aceptación y la disposición del equipo a participar en todas las fases del desarrollo de un producto. Esto motiva al equipo a participar cuando se realizan los cambios necesarios para lograr los objetivos definidos en cada Sprint o Release del producto. Pregunta 06 El papel del Product Owner por naturaleza es un cuello de botella. ¿Cómo apoya al Product Owner para que maximice el valor? 7

Un equipo de delivery de producto comprende a todos los involucrados en la entrega de un producto al mercado, incluidos los equipos de Scrum involucrados.

@marcoviaweb

Esta pregunta retoma el anterior. Una vez más, el candidato debe centrarse en explicar por qué involucrar al Equipo Scrum al principio del proceso de Product Discovery es beneficioso tanto para el Product Owner como para la organización. Esencialmente, en el equipo todos ganan o todos pierden.

Pregunta 07 ¿Cómo puede asegurarse de que un Equipo Scrum tenga acceso a los Stakeholders de un proyecto? Al responder a esta pregunta, el candidato debe explicar que no hay una manera fácil de garantizar el acceso a los Stakeholders. El candidato podría sugerir alentar a los Stakeholders a participar en una comunicación efectiva (transparente y útil). Los Sprint Review son un lugar útil para esto, y la interacción a menudo promueve mejores relaciones entre diferentes departamentos y unidades de negocios. Pregunta 08 ¿Cómo promueve una mentalidad ágil a través de los diferentes departamentos y a lo largo de una organización y, en pos de eso, cuál es su estrategia cuando capacita a los Stakeholders que no están familiarizadas con TI? Hay varias tácticas que un Scrum Master puede usar para involucrar a los Stakeholders en Scrum: ● Lo más importante es que un Scrum Master debe vivir y respirar los principios del Manifiesto Ágil. Ellos deben hablar con todos los miembros de la organización que participan en la construcción del producto y deben ser transparentes sobre lo que hacen. ● Los equipos de producto e ingeniería pueden producir evidencia, en presentaciones o de otra manera, demostrando a los Stakeholders que Scrum está reduciendo significativamente el tiempo de entrega desde la idea hasta el lanzamiento del producto. ● Los equipos de producto e ingeniería pueden demostrar que Scrum mitiga el riesgo (es decir, la predicción de cuándo podrían estar disponibles las nuevas características), lo que contribuye al éxito de otros departamentos en la planificación y ejecución. ● Un Equipo Scrum puede ser transparente con respecto a su trabajo y comprometer de manera proactiva a los Stakeholders invitándolos a reuniones, revisiones de Sprint y otros eventos donde el equipo comunica su actividad o progreso.

@marcoviaweb

●

La capacitación para todos en la organización, en particular los Stakeholders, es importante. Un enfoque práctico es organizar talleres diseñados para enseñar técnicas ágiles para colegas no técnicos.

Pregunta 09 ¿Cómo darías a conocer Scrum a los altos ejecutivos? Esta es una pregunta deliberadamente abierta destinada a alentar la discusión. Al responder a esta pregunta, el candidato debe explicar cómo difundir una mentalidad ágil en toda la organización o, idealmente, y más específicamente, cómo crearían una organización de aprendizaje que abarque la experimentación con el fin de identificar el mejor producto para los clientes. Es probable que un buen candidato hable sobre la necesidad de "vender" ágilmente a la organización para ganar los corazones y las mentes de los interesados. Al comienzo de una transición, cualquier organización muestra inercia al cambio, por lo que para superar esta resistencia, los ejecutivos y las Stakeholders deben saber qué tan ágil les beneficiará antes de que puedan comprometerse. Un enfoque práctico al presentar el Scrum a los ejecutivos sénior es organizar talleres para la gestión del nivel C. La aplicación de Scrum a nivel ejecutivo ha tenido éxito en el pasado. Los ejecutivos e incluso los directores clave, pueden obtener experiencia de primera mano con metodologías ágiles si se organizan como un Equipo Scrum. No hay respuestas correctas o incorrectas a esta pregunta. Las mejores prácticas deben tener en cuenta la cultura de la organización, el tamaño, la madurez del producto, los requisitos legales y de cumplimiento, y la industria en la que opera. Pregunta 10 Ya ha proporcionado capacitación de Scrum a los Stakeholders de su proyecto. Después de la fase inicial de tratar de aplicar los conceptos es cuando se encuentran los primeros obstáculos, algunos de estos actores comienzan a resistirse a la adopción continua. ¿Cuál es su estrategia y experiencia en el manejo de estas situaciones? El objetivo de esta pregunta es fomentar un intercambio de ideas y lecciones aprendidas cuando se supera la resistencia a la agilidad dentro de una organización. La familiaridad con los patrones de fracaso ágil, que son comunes a muchas organizaciones, demostrará la experiencia del candidato. El candidato también debe estar familiarizado con el desafío particular que enfrentan los gerentes intermedios en cualquier transición a prácticas ágiles. Pasar de un estilo de

@marcoviaweb

comando y control (es decir, administrar personas y decirles qué hacer) a un estilo de liderazgo de servicio - por lo que abandonar los principios de Taylor8 - no es para todos.

Refinamiento y estimación de backlog Pregunta 11 Con frecuencia el Product Owner convierte los documentos de requisitos recibidos de los Stakeholders en tickets y pide al equipo que los estimen. ¿Cómo te sientes acerca de este procedimiento? El Product Owner nunca debe convertir los documentos de requisitos9 recibidos de los Stakeholders en tickets, y un Scrum Master nunca debe aceptar tal procedimiento. No es nada más que un proceso en cascada10 disfrazado de una metodología pseudo-ágil. Si se supone que una organización se enfoca en entregar valor a sus clientes, es esencial que se abandone cualquier proceso que implique "requisitos" que un gerente de proyecto transmita a sus ingenieros. No hace ninguna diferencia si el gerente del proyecto se presenta como Product Owner. En su lugar, la organización debería comenzar a incluir a todos en el proceso de descubrimiento del producto, asegurando así una visión compartida de lo que se debe construir. Pregunta 12 ¿Qué tipo de información necesitaría de parte del Product Owner para darle al equipo una actualización sobre el producto y la situación del mercado? La información que un Scrum Master podría requerir del Product Owner cuando se quiere actualizar al equipo sobre el producto, o la reacción del mercado, incluiría cualquier información que pudiera proporcionar al Equipo Scrum una comprensión de por qué algo es valioso para los clientes. Dicha información puede ser de naturaleza cuantitativa (por ejemplo, datos analíticos que describen cómo se utiliza un proceso) o de naturaleza cualitativa (por ejemplo, transcripciones, screencasts o videos de una sesión de prueba de usuario). Una excelente sugerencia por parte del candidato sería que el Equipo Scrum participe en la recopilación de señales cualitativas participando en las entrevistas con los usuarios. 8

Los principios de la administración científica de F.W. Taylor son una teoría de la organización y la administración en la era industrial según la cual los trabajadores son vistos como recursos y deben ser gestionados como tales. 9 Los documentos de requisitos pueden incluir, por ejemplo, especificaciones de requisitos de software (SRS). 10 Un proceso de cascada es un proceso de diseño secuencial que generalmente se adhiere al modelo de cascada utilizado tradicionalmente en el desarrollo de software.

@marcoviaweb

Pregunta 13 ¿Quién debería escribir las historias de usuarios? Escribir historias de usuarios debe ser un esfuerzo conjunto entre todos los miembros de un Equipo Scrum. Si no es así, el equipo podría sentir que no es propietario de las historias, lo que inevitablemente lleva a menos o ningún compromiso, motivación reducida y, en última instancia, a un producto de menor calidad. Pregunta 14 ¿Cómo es una buena historia de usuario? ¿Cuál es su estructura? Una buena historia de usuario ● incluye una descripción, ● tiene criterios de aceptación definidos, ● se puede entregar dentro de un solo Sprint, ● tiene todos los entregables UI disponibles, ● tiene todas las dependencias (probables) identificadas, ● tiene criterios de rendimiento definidos, ● tiene criterios de seguimiento definidos, y ● es estimado por el equipo.

Pregunta 15 ¿En qué consiste la Definition of Ready? La "Definition of Ready" es un acuerdo entre el Equipo Scrum y el Product Owner sobre lo que debe incluirse en una historia de usuario (antes de que la historia pueda considerarse lista para su estimación). Esto define cómo es una buena historia de usuario. La discusión en la pregunta 14 incluye un resumen de lo que debe incluir una buena historia de usuario. Otro enfoque es utilizar un marco para las historias de usuario, como la mnemotecnia INVEST de Bill Wake: ● Independiente (Independent). La historia de usuario debe ser autocontenida, de manera que no haya una dependencia inherente con otra historia de usuario. ● Negociable (Negotiable). Hasta que se conviertan en parte de una iteración, las historias de usuario siempre pueden cambiarse y reescribirse. ● Valioso (Valuable). Una historia de usuario debe entregar valor al usuario final. ● Estimable (Estimable). Siempre se debe poder estimar el tamaño de una historia de usuario.

@marcoviaweb

● ●

Pequeña (Small). Las historias de usuario no deben ser tan grandes como para que sea imposible planificarlas, asignarles tareas y priorizarlas con cierta certeza. Comprobable (Testable) La historia del usuario (o su descripción relacionada) debe proporcionar la información necesaria para hacer posible el desarrollo de la prueba.

Pregunta 16 ¿Por qué las historias de usuarios no se estiman en horas hombre? Estimar historias de usuarios en horas hombre nunca es una buena idea. Se desvía intencionalmente el énfasis del verdadero propósito del proceso de estimación: crear una comprensión compartida de la tarea que está por delante entre todos los miembros del Equipo Scrum. Ergo, la estimación en sí es sólo un subproducto. Estimar es a menudo complicado cuando: ● software legacy está involucrado, ● un equipo se enfrenta a una deuda técnica significativa, o ● un equipo está compuesto principalmente por miembros junior. Los puntos de historia11 son mucho más adecuados para estimar que las horas de trabajo en todas las situaciones, pero especialmente en situaciones difíciles, porque reflejan con precisión tanto la complejidad de la tarea como el esfuerzo requerido para completarla. El uso de horas de trabajo en lugar de puntos de historia generalmente cambia el enfoque de la creación de valor para los clientes a la gestión de proyectos y presupuestos más tradicional, lo que impone un proceso en cascada. El candidato mencionaría esta discusión en la comunidad ágil sobre si las estimaciones son útiles en general. Probablemente, también señalaría el concepto de "no estimaciones" (por ejemplo, #noestimates). Pregunta 17 El Product Owner tiende a agregar ideas de todo tipo en el Product Backlog como un recordatorio para trabajar en ellas en una etapa posterior. Con el tiempo, esto ha llevado a más de 200 tickets en varias etapas. ¿Qué piensas sobre esto? ¿Puede un Equipo Scrum trabajar en 200 tickets? Cualquier Product Backlog mayor que el alcance de dos o tres Sprints no es manejable. El uso indebido de un backlog al agregar cientos de elementos es una clara señal de que el Product Owner necesita la ayuda del Equipo Scrum o del Scrum Master para hacer frente a la afluencia de ideas, sugerencias y requisitos. Un retraso más pequeño evita la mala asignación de recursos; un retraso mayor es una indicación de desperdicio. 11

Los puntos de historia son unidades de medida que expresan las estimaciones del esfuerzo total requerido para implementar completamente un elemento del Product Backlog.

@marcoviaweb

El candidato debe dejar claro que apoyaría al Product Owner en la gestión con el tamaño del Product Backlog y con el procesamiento de los aportes de las Stakeholders.

Sprint planning Pregunta 18 ¿Cómo puede el Scrum Master contribuir con el Sprint Planning de manera que permita al Equipo Scrum trabajar solo en las historias de usuario más valiosas? Es una prerrogativa del Product Owner definir el alcance de un próximo Sprint identificando y priorizando las historias de usuario más valiosas del Product Backlog, y es deber del Scrum Master apoyar al Product Owner en esto. En consecuencia, la mejor manera para que un Scrum Master se asegure de que un Equipo Scrum esté trabajando en las historias de usuario más valiosas es: 1. garantizar que el Equipo Scrum esté involucrado en el proceso Product Discovery en una etapa temprana; 2. garantizar que el proceso de refinamiento del Product Backlog sea bien comprendido tanto por el Equipo Scrum como por el Product Owner (esto debería respaldarse, por ejemplo, mediante la creación de una Definition of Ready estándar para historias de usuario); y 3. garantizar que todas las historias de usuario se crean en un esfuerzo de colaboración entre el Product Owner y el Equipo Scrum (el objetivo es una comprensión compartida de las historias de usuario y, por lo tanto, la propiedad conjunta). El candidato debe tener en cuenta que aunque el Product Owner define el alcance del Sprint (y la meta del Sprint), es una prerrogativa del Equipo Scrum para abordar la deuda técnica y los errores durante el mismo Sprint (un equipo debe poder asignar hasta 25% de su capacidad disponible para esto). Pregunta 19 ¿Con qué métricas evaluarías el valor de una historia de usuario? Existen mediciones tanto cuantitativas como cualitativas que pueden usarse para evaluar el valor de una historia de usuario o si su inversión vale la pena. Estos pueden incluir: ● aumento de ingresos, ● los beneficios de reducción de costos logrados por las mejoras de procesos internos ● aumentos en las tasas de satisfacción del cliente (NPS12), 12

NPS® (Net Promoter Score) es una métrica de fidelidad del cliente y una marca comercial registrada de Fred Reichheld, Bain & Company y Satmetrix Systems.

@marcoviaweb

● ●

Incrementos en los registros para nuevos productos, o comentarios positivos recibidos por el equipo de atención al cliente.

Pregunta 20 ¿Cómo facilita la selección de historias de los usuarios de manera que se elijan las historias más valiosas sin anular la prerrogativa del Equipo Scrum para definir su propio compromiso? Si un Equipo Scrum se involucra con la suficiente anticipación en la selección de historias del usuario (preferiblemente mediante la creación conjunta de las historias con el Product Owner) o en el Producto Discovery, es probable que un Scrum Master no tenga que proporcionar orientación para ver que se elijan las historias más valiosas. La mayoría de los equipos apoyarán las historias de usuario elegidas por el Product Owner para un Sprint determinado. Si un equipo recurre a elegir a su antojo - elegir historias de usuario solo para satisfacer sus preferencias personales - durante el Sprint planning, el proceso de refinamiento del backlog debe ser inspeccionado seriamente. Con toda probabilidad, el Product Owner está eligiendo historias de usuario que no maximizan el valor para el cliente. Pregunta 21 ¿Cuánta capacidad de un Equipo Scrum, durante un Sprint regular, consideraría adecuada para refactorizar? ¿Arreglando errores importantes? ¿Explorando nuevas tecnologías o ideas? Además de los Sprints durante los cuales hay tareas críticas y urgentes que deben abordarse (como solucionar un problema que ha desconectado el sitio web), una buena regla general es una asignación de 15-10-5 a la capacidad de un Equipo Scrum para refactorizar, corregir, y la investigación. En concreto, esto significa dedicar ● 15% de la capacidad de un equipo para la deuda técnica, ● 10% de la capacidad de un equipo para errores, y ● 5% de la capacidad de un equipo para spikes exploratorios (cuando sean potencialmente útiles). Un Equipo Scrum puede, por supuesto, desviarse de esto cuando se trata de Sprints individuales. Pero, en general, las asignaciones consistentes cumplirán con la calidad del código y los requisitos de mantenimiento de la mayoría de las aplicaciones de software. Pregunta 22

@marcoviaweb

¿Debería el Product Owner asignar historias o tareas de usuario a miembros individuales de un Equipo Scrum? El Product Owner que asigna individualmente historias de usuarios a los miembros de un Equipo Scrum no es ágil, y si el Product Owner está haciendo esto, es necesario detenerlo. Se supone que los equipos de Scrum son auto-organizados. La asignación de historias de usuarios y la distribución de tareas entre los miembros de un Equipo Scrum es una prerrogativa del propio equipo. Prevenir este error debería ser una de las preocupaciones más apremiantes del Scrum Master. Pregunta 23 ¿Cómo lidiar con los miembros del equipo que eligen tareas a su antojo? Un Equipo Scrum tiene autonomía en la forma en que sus miembros eligen distribuir las tareas, por lo que puede ser que una presunta selección de tareas por parte de los miembros individuales del equipo sea, de hecho, una parte valiosa y crucial del camino del equipo hacia su desempeño. Sin embargo, si los miembros del equipo se quejan de cómo los demás están eligiendo sus tareas, el Scrum Master debe abordar el problema. Una capacitación adicional podría ayudar a algunos miembros del equipo a adaptarse a una mayor variedad de tareas. O quizás, otros miembros del equipo deban ser expulsados suavemente de su zona de confort para que puedan elegir más fácilmente diferentes tipos de tareas sobre las que se han acostumbrado. Pregunta 24 A una historia de usuario le faltan los diseños finales de la interfaz de usuario, pero el equipo de diseño se compromete en entregarlo el segundo día del próximo Sprint. El Product Owner está bien con esta situación, y presiona para que la historia del usuario se agregue al Sprint Backlog. ¿Qué piensas sobre este escenario? El hecho de que se agregue una historia de usuario incompleta al Sprint Backlog depende de las preocupaciones actuales del equipo y de la experiencia con las circunstancias que causaron que la historia no cumpliera con su Definition of Ready. En el caso de un diseño de interfaz de usuario (UI) incompleto o faltante, por ejemplo, si es casi seguro que el equipo de diseño realice la entrega porque lo ha hecho en el pasado, si la historia del usuario es de gran valor, si la historia puede ser lograda dentro del Sprint a pesar de que sus entregables de UI llegan tarde, y si el equipo lo acepta, entonces una excepción puede ser aceptable. Tenga en cuenta que las excepciones tienen una tendencia a convertirse en prácticas aceptadas. No se debe permitir que una intención de la organización de ser ágil omita el refinamiento de la cartera de pedidos y el proceso de Sprint Planning. El candidato debe ser

@marcoviaweb

consciente de que tales situaciones no son sostenibles. Además, si la implementación de una historia de usuario sujeta a tal excepción falla, nadie se molestará en leer la letra pequeña y reconocer que se ha hecho una excepción. En su lugar, lo más probable es que vean que el proceso ágil en sí ha fallado. Sus candidatos pueden aceptar o rechazar excepciones al proceso ágil. Pero también deben poder analizar las situaciones en las que se han hecho excepciones y explicar el daño colateral al que puede estar expuesto el Equipo Scrum. Pregunta 25 Un miembro del Equipo Scrum no quiere participar en el Sprint planning y considera que las reuniones son una pérdida de tiempo. ¿Cómo lidias con esta actitud? Si un miembro de un Equipo Scrum no quiere participar en el Sprint Planning y considera que las reuniones son una pérdida de tiempo, están mostrando un tipo de comportamiento pasivo-agresivo. Aunque no es específico de Scrum, este es un problema porque la actitud subyacente es tóxica y afectará tanto la formación como el rendimiento del equipo. Cuando el miembro de un Equipo Scrum se comporta como se describe, el Scrum Master del equipo debe actuar. El comportamiento contraproductivo no puede ser ignorado ni tolerado si el equipo debe continuar funcionando. Es probable que una acción efectiva requiera una serie de pasos escalonados: 1. El Scrum Master debe comenzar dirigiéndose al miembro del equipo en privado para discutir su reserva y, quizás, más coaching o un período de capacitación más largo. 2. Después de una discusión privada, todo el equipo puede participar haciendo de esta situación un tópico de discusión durante una o más retrospectivas. Esto permite al equipo ofrecer su apoyo. 3. Si todavía no hay ningún cambio en la actitud del miembro del equipo, se recomienda una reunión con el miembro del equipo y su gerente. 4. Si no se puede lograr ningún cambio, podría ser posible reasignar al colaborador a otro equipo (probablemente no ágil), o a un equipo kanban que probablemente no obligue al miembro del equipo a salir de su zona de confort. Situaciones como las que se describen resaltan que Scrum no es para todos.

Daily Scrums Pregunta 26 ¿Recomendaría Standups formales para todos los equipos, sin importar el tamaño o el nivel de experiencia?

@marcoviaweb

Al responder a esta pregunta, su candidato debe mostrar sentido común con respecto a los Standups formales. Los Standups son una parte importante de Scrum, pero no todos los Standups tienen que ser formales. Un equipo pequeño, experimentado y co-localizado puede usar un descanso para tomar café para su standup. Sin embargo, adoptar un enfoque relajado e informal para los Standups de un equipo grande con varios miembros juniors probablemente no logrará nada, si es primero no se torna un caos. Para equipos grandes, es necesario una reunión formal para proporcionar formato y orientación. Para los equipos distribuidos que no pueden reunirse fácilmente para tomar un café, es necesario un standup formal para adaptarse a las limitaciones técnicas, y debe programarse y realizarse de manera organizada. Pregunta 27 ¿Crees que los miembros más experimentados del equipo esperen hasta el próximo standup en pedir ayuda para superar un impedimento? Cuando surge un impedimento, los miembros de un Equipo Scrum nunca deberían tener que esperar, ni por un standup ni por ningún otro evento, para pedir ayuda. Un equipo que espera para solicitar ayuda es un equipo que retrasa su progreso. Si los miembros más experimentados de un Equipo Scrum están esperando el próximo standup antes de pedir ayuda o lidiar con un impedimento, el Scrum Master debe hacer un trabajo de Team Building. Pregunta 28 ¿Cómo maneja a los miembros del equipo que "lideran" los Standups, convirtiendo el evento en una sesión de informe para ellos mismos? No hay roles oficiales de liderazgo en Scrum. Sin embargo, no es raro que algunos miembros de un Equipo Scrum asuman el liderazgo. Esto suele suceder cuando un miembro de un equipo en particular posee una experiencia (técnica) superior, habilidades de comunicación o simplemente un mayor nivel de participación. Todos los equipos pasan por las etapas de desarrollo de grupo de Tuckman: formación, enfrentamiento, normalización y desempeño. Los equipos de Scrum no son una excepción. Es importante que cuando un miembro de un Equipo Scrum asuma el liderazgo, esto no resulte en que otros miembros se reporten a ellos. Un Scrum Master debe estar atento e intervenir si es necesario para garantizar que todos los miembros del equipo se comuniquen y trabajen juntos, durante las luchas y otras cosas, en el espíritu de Scrum.

@marcoviaweb

Pregunta 29 ¿Cómo gestionas a los miembros del equipo que consideran que los Standups son una pérdida de tiempo y, por lo tanto, son tardíos, poco cooperativos o simplemente no asisten? Refiérase a la pregunta 25, donde se aborda en detalle cómo abordar esta actitud similar y este problema de comportamiento. Las respuestas del candidato deben abordar esos mismos puntos. Pregunta 30 Los Standups del equipo no son atendidas por ningún stakeholder. ¿Cómo cambiarías eso? Hacer esta pregunta puede desencadenar fácilmente una discusión filosófica sobre si se debe permitir a los Stakeholders ​participar en las reuniones de un Equipo Scrum. Intenta evitar esto. Si las Stakeholders participan en los Standups de un equipo, ¿es probable que resulte en una forma de reporte que elude las reglas de Scrum? No necesariamente. Es bueno si se puede hacer alguna adaptación de Scrum para que funcione para una organización. No se debe descartar la posibilidad de permitir que los Stakeholders ​participen en los Standups si el equipo lo encuentra aceptable. De hecho, si los Stakeholders asisten a los Standups regularmente, esto invariablemente mejora significativamente la comunicación entre un equipo y los Stakeholders. Entonces, ¿cómo hace un Scrum Master para alentar a los Stakeholders a asistir a los Standups? Hacer que valga la pena su tiempo. El Scrum Master puede lograr esto de varias maneras: por ejemplo, puede ofrecer a los Stakeholders la oportunidad de aprender los primeros detalles de un nuevo producto o feature, o pueden optar por darles la oportunidad de hacer preguntas a los ingenieros directamente (sin pasar por el Product Owner). Pregunta 31 ¿Cómo abordas los Standups con equipos distribuidos? Los Standups para los equipos Scrum cuyos miembros se distribuyen entre diferentes oficinas o trabajan de forma remota no son muy diferentes de los Standups para los equipos Scrum cuyos miembros comparten la ubicación. La excepción es que los equipos distribuidos que comparten la actividad del tablero pueden requerir videoconferencias cuando se trabaja con tableros offline que se reflejan entre sí.

@marcoviaweb

Si un Equipo Scrum está usando un software de planificación o gestión de tareas online como JIRA, los tableros del equipo pueden estar online y las actualizaciones pueden realizarse en pantalla. Esto generalmente facilita que los miembros de un equipo distribuido sigan la actividad del tablero. Con los tableros online en su lugar, una llamada de Skype o Google Hangouts13 probablemente será suficiente para que un equipo distribuido tenga su Standup. Pregunta 32 ¿Puedes dibujar un ejemplo del tablero kanban offline de un Equipo Scrum? En esta pregunta, el calificador ‘kanban’ es un teaser. Cualquier persona que realice una entrevista para el rol de Scrum Master debe poder dibujar una simple tablero offline. Normalmente hay cinco columnas (o filas) en un tablero offline: 1. Backlog 2. en progreso 3. revisión de código 4. aseguramiento de la calidad 5. Hecho Se puede incluir información adicional o adjuntarse a cualquier tipo de tablero, por ejemplo, ● fechas de Sprint o reuniones, ● pruebas de aceptación del usuario (UAT), ● la Definition of Ready, ● un gráfico de quema (progreso y trabajo restante a lo largo del tiempo), y ● un estacionamiento (temas para discusión futura). El candidato debe mencionar que un Scrum Master no está obligado a proporcionar al Equipo Scrum un tablero offline. Una tablero es responsabilidad del equipo que trabaja con ella. Sin embargo, el Scrum Master debe proporcionar un taller introductorio sobre el tema si ningún miembro del equipo está familiarizado con los tableros offline.

Retrospectivas Pregunta 33 ¿Quiénes deberían participar en una retrospectiva?

13

Skype y Google Hangouts son populares aplicaciones de computadora basados en video.

@marcoviaweb

Solo los miembros inmediatos de un Equipo Scrum deben participar en las retrospectivas de ese equipo. Es importante es que los gerentes de los miembros de un equipo no estén presentes. La única excepción es el Product Owner. En general, es una buena idea incluir al Product Owner en las retrospectivas de un Equipo Scrum porque es un miembro crucial del equipo. Pero no es obligatorio. Algunos equipos pueden preferir que el Product Owner no participe, y los deseos de un equipo siempre deben ser considerados. Pregunta 34 ¿Se debe controlar la “salud” de un equipo durante una retrospectiva o es innecesario hacerlo? Si lo haces, ¿Cómo lo harías? Medir la “salud” de un Equipo Scrum, es decir, obtener una idea sobre los niveles actuales de compromiso y satisfacción, es útil para identificar tendencias que pueden afectar la productividad. Un método efectivo para medir la “salud” de un Equipo Scrum es hacer circular un cuestionario de opción múltiple en las retrospectivas del equipo. Un cuestionario que requiere solo dos minutos para completarse y utiliza una escala simple para cada una de las preguntas suele ser mejor, por ejemplo. 1. terrible 2. pobre 3. neutral 4. bueno 5. excelente Durante la retrospectiva, al completar el cuestionario, el equipo debe discutir los resultados con el objetivo de descubrir cualquier inquietud o frustración que puedan tener. Pregunta 35 ¿Qué formatos de retrospectiva has usado en el pasado? Hay varios formatos de retrospectiva de uso común, y cada uno está diseñado para adaptarse a diferentes situaciones. El candidato debe tener experiencia en la aplicación de más de uno de estos formatos y debe poder compartir su lógica por haberlo hecho: El formato clásico ● ¿Qué hicimos bien? ● ¿Qué deberíamos haber hecho mejor? El formato del barco

@marcoviaweb

● ●

¿Qué nos está empujando hacia adelante? ¿Qué nos está frenando?

La retrospectiva de la estrella de mar. ● Empezar a hacer ... ● Hacer menos de ... ● Hacer más de ... ● Deja de hacer ... ● Continuar haciendo ... Los formatos Diana Larsen y Esther Derby14. ● Preparar el escenario ● Recopilar datos ● Generar ideas ● Decide qué hacer ● Cerrar la retrospectiva. Pregunta 36 ¿Cómo prevenir el aburrimiento durante las retrospectivas? Cuando se requiera asistir a una retrospectiva aburrida, los miembros de un Equipo Scrum se aburrirán. Existen muchas posibilidades de variación que pueden usarse para evitar que una retrospectiva sea aburrida y que los miembros del equipo se aburran. Una ubicación diferente, un formato diferente y el acortamiento o alargamiento del Time Box asignado son solo algunas de las variaciones que se pueden probar. El Scrum Masters también puede usar los elementos de acción elegidos por un equipo para alentar y estructurar las discusiones sobre temas que son importantes para el equipo, creando así un compromiso a través del reconocimiento. Los sitios web como Retromat ofrecen cientos de juegos y ejercicios diferentes para que las retrospectivas sean agradables y valiosas para todo el equipo. No existe una solución única y, por lo tanto, no hay una sola respuesta correcta, ni al aburrimiento ni a esta pregunta. Lo importante es que su candidato reconozca que el aburrimiento con la rutina puede convertirse en un problema, y ​que hay formas de lidiar con él. Pregunta 37

14

Este es el formato descrito en el libro Agile Retrospectives: Making Good Teams Great por Diana Larsen y Esther Derby.

@marcoviaweb

Si el equipo elige elementos de acción razonables pero no los entrega, ¿cómo abordaría la situación? Durante una retrospectiva, generalmente se espera que los miembros de un Equipo Scrum elijan una serie de elementos de acción (tareas a realizar). Si estos elementos de acción no se completan posteriormente de manera oportuna, el Scrum Master debe realizar un seguimiento. Es posible que un equipo no esté completando los elementos de acción que eligió porque se encontraron con un impedimento externo. Si este es el caso, el Scrum Master debe abordar la causa, y el equipo puede ponerse al día durante un Sprint posterior. Sin embargo, si no hay un impedimento externo, es probable que el problema se deba a la motivación, la actitud o los problemas personales dentro del equipo. En este último caso, el Scrum Master debe proporcionar a los miembros del equipo infractor el estímulo o la motivación suficientes para superar el problema, y ​luego ver que cumplan con sus compromisos. Si un equipo no completa los elementos de acción que eligió y el problema no se puede resolver, seleccionar elementos de acción se convierte en un ejercicio inútil y el equipo sufrirá las consecuencias. Pregunta 38 ¿Cómo recomendarías realizar el seguimiento de los elementos de acción? Se espera que un Scrum Master haga el seguimiento de los elementos de acción (tareas a realizar) que los miembros de un Equipo Scrum seleccionan durante las retrospectivas de su equipo. Una buena manera para que un Scrum Master haga esto es comenzar a hablar sobre el estado de los elementos de acción seleccionados durante la última retrospectiva antes de elegir otros nuevos iniciando una discusión en el Inicio de cada nueva retrospectiva. Si esta discusión descubre elementos de acción seleccionados durante una retrospectiva anterior que no se completó como se esperaba, el equipo debe entender por qué y evitar que vuelva a ocurrir.

Métricas Agile Pregunta 39 ¿Existe alguna métrica estándar a la que harías seguimiento? Si es así, ¿Cuál y con qué propósito?

@marcoviaweb

Al realizar el seguimiento de las métricas a nivel organizativo, los efectos de cualquier proceso o cambio se pueden medir cuantitativamente con un modelo de puntuación de métricas. Los impactos medidos incluirían: ● la capacidad de responder a los cambios y producir un código valioso (por ejemplo, la capacidad de desglosar las funciones); ● la dualidad de la planificación tanto en el lanzamiento como en el Sprint; ● la flexibilidad para adaptarse a los hechos cambiantes, los cuadros de tiempo y la entrega continua; ● la frecuencia con la que los Equipos Scrum están ofertando por historias, y si los equipos están ejerciendo alguna libertad en su enfoque para resolverlos; ● la creación y el crecimiento de una cultura de aprendizaje compartido; y ● La continuidad con la que se entregan las características. El diseño de un modelo de puntuación de métricas debe tener en cuenta la madurez ágil de la organización, de modo que los aspectos cualitativos puedan cuantificarse y, por lo tanto, compararse. Si el modelo de puntuación de métricas se puede diseñar antes de introducir un marco ágil en una organización, se debe estudiar el status quo para establecer una línea de base contra la cual medir estos efectos y rastrear su evolución en el tiempo. Cualquier métrica útil para medir los efectos de un proceso o cambio relevante debe registrarse con regularidad, durante todo el viaje ágil. Encuestar a los miembros de los Equipos Scrum de una organización es un buen comienzo. Pregunta 40 El Equipo Scrum no está cumpliendo con los compromisos y su velocidad es inestable. ¿Cuáles son las razones más probables de este problema y cómo lo abordaría con el equipo? Si un Equipo Scrum muestra una velocidad inestable y no cumple con sus compromisos, sugiere que la velocidad se está utilizando como la métrica prevalente para medir el progreso de ese equipo. El candidato debe mencionar esto y hablar sobre la notoriedad de la "velocidad" como una métrica de la industria para medir el progreso de un equipo. Además, deberían poder explicar por qué la velocidad es una métrica ágil dudosa, y señalar que las métricas cuantitativas no son ideales para medir el progreso de un equipo en el dominio del Scrum. Hay muchos factores que pueden hacer que la velocidad de un Equipo Scrum sea inestable: ● nuevos miembros del equipo están siendo incorporados; ● miembros experimentados que abandonan el equipo; ● el equipo que trabaja en territorio inexplorado; ● el equipo que trabaja con código heredado, probablemente sin documentar; ● el equipo se encuentra con una deuda técnica inesperada; ● vacaciones y baja por enfermedad reduciendo la capacidad del equipo; ● una intervención ejecutiva que cambia el alcance de un Sprint; y

@marcoviaweb

●

el equipo aborda los errores prioritarios.

Otra causa común para que un Equipo Scrum no cumpla constantemente con sus compromisos es que los compromisos del equipo con frecuencia son demasiado agresivos. Esto podría indicar que las historias de usuario están mal preparadas (por ejemplo, no cumplen con la Definition of Ready del equipo), lo que dificulta la estimación de las historias por parte del equipo. A la inversa, los proyectos que reciben el equipo pueden sufrir un código heredado mal documentado, una deuda técnica excesiva o simplemente un código demasiado defectuoso y mal escrito, todo lo cual hace que la estimación sea una apuesta. El candidato no debe alinearse con la falacia de que una adopción ágil funciona solo porque el compromiso y la velocidad de un Equipo Scrum están alineados. Pregunta 41 ¿A qué métricas ágiles cualitativas consideraría realizar seguimiento? El propósito de las métricas cualitativas en Agile es obtener información sobre cómo uno o más de los equipos Scrum de una organización están progresando con Agile. Hay varias pruebas de autoevaluación disponibles que un Equipo Scrum puede ejecutar regularmente para recopilar métricas cualitativas sobre su implementación de Scrum; Scrum Checklist por Henrik Kniberg es un buen ejemplo. El intervalo de prueba a través de la autoevaluación es cada 4 a 12 semanas, con equipos de menor madurez que realizan sus pruebas en el extremo inferior de este rango. Los valores individuales registrados por estas pruebas no son muy importantes, pero la tendencia en el tiempo es. Para visualizar estas tendencias, el Scrum Master deberá agregar los resultados; en el caso del Checklist de Henrik Kniberg, se puede crear un mapa de práctica ágil15 a lo largo del tiempo. Si bien las pruebas de autoevaluación, como el Checklist de Henrik Kniberg, suelen ser ejercicios de equipo para registrar métricas de implementación, las métricas de sentimiento se capturan mejor mediante ​encuestas de opinión anónimas para asegurar la participación de los miembros más introvertidos del equipo. En las encuestas de opinión, las preguntas típicas para registrar métricas de sentimiento incluyen: ● ¿Qué valor entregó el equipo en el último Sprint? ● ¿Ha aumentado o disminuido el nivel de deuda técnica durante el último Sprint? ● ¿Estás contento de trabajar con tus compañeros de equipo? ● ¿Recomendaría su empleador (o cliente) a un amigo que busca un nuevo trabajo? Es mejor hacer encuestas de opinión después de cada Sprint; estas encuestas solo deben requerir unos segundos para completar. Al igual que con las pruebas de autoevaluación, los valores individuales registrados al realizar encuestas de opinión anónimas no son muy

15

Un mapa de práctica ágil es un método de organización de historias de usuario para evitar fallas que pueden ser causadas por la entrega incremental.

@marcoviaweb

importantes, lo que importa es la tendencia en el tiempo. Las tendencias derivadas de estas encuestas son excelentes puntos de conversación durante las retrospectivas de un equipo. Con respecto a las métricas en general, el candidato debe respaldar el Manifiesto Ágil y su principio de transparencia: todas las métricas deben estar disponibles para todos los miembros de un Equipo Scrum, y en gran parte también para aquellos que trabajan en la Organización del Product Delivery16 en general.

Cómo iniciar una transición a Scrum Pregunta 42 ¿Cómo te prepararías para iniciar la transición a Scrum? Si no sabes a dónde vas, cualquier camino te conduce allí. El candidato debe comprender que una transición ágil debe tener un objetivo y una meta, lo que significa planificar con anticipación. Prepararse para iniciar la transición a Scrum es escuchar y observar: el candidato debe expresar interés en entrevistar a tantos miembros del equipo y Stakeholders como sea posible, antes de entrar en acción. Estas entrevistas deben incluir a todos, sin importar su rol (ingenieros, profesionales de control de calidad, control de calidad de vida y UX, gerentes de producto) para identificar los patrones subyacentes a los problemas actuales, fallas y disfunciones dentro de la organización. La fusión de esos patrones con los problemas técnicos y comerciales más apremiantes identificará los objetivos más probables para los primeros equipos de Scrum. Esta fase de observación, durante la cual un Scrum Master realiza sus entrevistas, generalmente requerirá entre cuatro y ocho semanas, dependiendo del tamaño y la estructura de la organización. La capacitación de los futuros miembros del equipo y las Stakeholders debe comenzar y ser paralela a las entrevistas. Crear los primeros Equipos Scrum a partir de los departamentos de ingeniería y productos existentes es el segundo paso para iniciar una transición al Scrum. Su candidato debe ser capaz de esbozar el plan aproximado de una transición y abordar los problemas comunes que pueden surgir durante el inicio. Pregunta 43 ¿Cómo crearías el primer Equipo Scrum?

16

La Organización del Product Delivery es, efectivamente, todos los miembros de una organización que participan en llevar el producto al mercado.

@marcoviaweb

Cuando una organización está haciendo la transición a Scrum y al mismo tiempo se enfrenta a importantes problemas de organización, comerciales y técnicos, los miembros fundadores de sus Equipos Scrum deben ser voluntarios que entiendan completamente el desafío que se les presenta, en lugar de personas que entran en servicio. Los mejores voluntarios son aquellos deseosos de demostrar que volverse ágil es la forma más efectiva de alcanzar un objetivo. Los candidatos para el rol de Scrum Master deben ser lo suficientemente astutos como para sugerir invitar a todos los miembros del equipo de entrega de productos, así como a los ejecutivos de nivel C que patrocinan la transición, a una reunión inicial. El objetivo de una reunión de inicio de la transición es apoyar a los miembros de los equipos de ingeniería y de productos en la forma en que deciden autoorganizarse en los primeros equipos de Scrum multifuncionales. Las reuniones de inicio de la transición pueden durar algunas horas o varios días, según las circunstancias de una organización en particular. A pesar de la importancia de la reunión de inicio para una transición de Scrum, profundizar en su estructura tomará mucho tiempo de la entrevista. Es más importante que sus candidatos presenten una breve hoja de ruta de lo que debería suceder a continuación para los equipos de Scrum recién formados. Si bien dependen algo de las habilidades, la experiencia y la capacitación existentes de los miembros de los nuevos Equipos de Scrum de una organización, sus candidatos deben anticipar tener que enseñar los conceptos básicos del Scrum después de una reunión de inicio. Podrían proponer hacer esto a través de una serie de talleres o capacitación en el trabajo con ejercicios de refinamiento del Product Backlog, escribiendo historias de usuarios, estimando y creando tableros offline. Pregunta 44 ¿Qué recomendaría trabajar primero a un Equipo Scrum de reciente formación? El primer problema crítico para la mayoría de los Equipos de Scrum recién formados es el atraso existente del producto heredado. Las respuestas a esta pregunta no tienen por qué referirse a las etapas de desarrollo del equipo de Tuckman, a los ejercicios adicionales de creación de equipos o a cualquier tipo de capacitación o taller sobre Scrum que no esté relacionado con la acumulación de productos. Es una rara ocasión para que un Scrum Master comience desde cero con un equipo completamente nuevo y sin un producto existente, incluso más en una organización naciente como una startup. En la mayoría de los casos, es una organización de entrega de productos existente con productos y servicios existentes que "se volverá ágil". Para estos casos, el candidato debe señalar que el primer paso práctico es refinar el Product Backlog heredado.

@marcoviaweb

El Product Backlog heredado por si es un artefacto interesante porque proporciona información completa sobre el historial de la organización del Product Delivery: este atraso en particular permite identificar la deuda de la organización, las insuficiencias de los procesos, las decisiones cuestionables de los productos y otros anti-patrones. Al observar una acumulación de productos heredados, un candidato excelente podrá señalar algunos de estos anti-patrones (por ejemplo, tickets obsoletos o mal conservados), y ofrecer una buena idea sobre cómo transformar el Backlog heredado en un Backlog bien refinado y actual del producto, de modo que un nuevo Equipo Scrum (incluido el Product Owner) pueda trabajar con él. Los candidatos deben mencionar que la ejecución de un taller de refinamiento del Product Backlog crea una buena oportunidad para proporcionar un nuevo Equipo Scrum y capacitación práctica del Product Owner con Scrum. Esto se debe a que un taller de refinamiento de trabajos pendientes generalmente cubrirá la creación de historias de usuarios, la transferencia de conocimiento entre los miembros del equipo, el proceso de estimación (si corresponde), las métricas de introducción ágil, el análisis técnico de deudas y otros temas críticos para Scrum.

Anti-patrones de Scrum Pregunta 45 ¿En qué anti-patrones podría caer un Scrum Master durante un Sprint? Los anti-patrones en los que un Scrum Master podría caer durante un Sprint impedirán la productividad de un equipo. Los más típicos de estos se resumen aquí. Es la obligación del Scrum Master evitar que estos anti-patrones se manifiesten. Interrupción del flujo El Scrum Master permite a las Stakeholders interrumpir el flujo de trabajo del equipo de desarrollo durante el Sprint. Hay varias formas posibles de que las Stakeholders puedan interrumpir el flujo de un equipo durante un Sprint: ● El Scrum Master tiene una política de Laissez-Faire con respecto al acceso al equipo de desarrollo. ● El Scrum Master no se opone cuando la administración invita a los ingenieros a reuniones aleatorias como expertos en la materia. ● Por último, el Scrum Master permite que las Stakeholders o los administradores convierten el Scrum diario en una sesión de informes. Falta de apoyo El Scrum Master no es compatible con los miembros del equipo que necesitan ayuda con una tarea.

@marcoviaweb

Los equipos de desarrollo a menudo crean tareas que un ingeniero puede terminar en un día. Sin embargo, si alguien tiene dificultades con una tarea durante más de dos días sin expresar que necesita ayuda, el Scrum Master debe abordar el problema. Es importante destacar que esta es también la razón para marcar las tareas en un tablero físico con puntos rojos cada día si no se han movido a la siguiente columna. Microgestión El Scrum Master no impide que el Product Owner, o cualquier otra persona, asigne tareas a los ingenieros. El equipo de desarrollo normalmente se organiza sin intervención externa. Y el Scrum Master debería actuar como el escudo del equipo a este respecto. #NoRetro El Scrum Master no recopila datos durante el Sprint que respalda al equipo en la próxima retrospectiva. Esto se explica por sí mismo. Pregunta 46 ¿Qué anti-patrones sabes que pueden ocurrir durante una retrospectiva? Los anti-patrones típicos de una retrospectiva incluyen: Pérdida de tiempo El equipo no valora colectivamente la retrospectiva. Si algunos miembros del equipo consideran que la retrospectiva tiene poco o ningún valor, lo más frecuente es que la retrospectiva sea el problema. ¿Es el mismo procedimiento cada vez, ritualizado y aburrido? Tener una meta-retrospectiva sobre la retrospectiva en sí. Cambiar el lugar. Tener una cerveza o vino retrospectiva. Hay muchas cosas que un Scrum Master puede hacer para que las retrospectivas sean interesantes y valiosas, reduciendo la tasa de ausencias. Además, es bueno recordar que (en nuestra experiencia) a los introvertidos, no solo a los extrovertidos, les gusta participar en retrospectivas. Presos Algunos miembros del equipo solo participan porque están obligados a formar un equipo. No presione a nadie para que participe en una retrospectiva. En su lugar, haz que valga la pena. El impulso de mejorar continuamente como equipo debe ser alimentado por una motivación intrínseca, no por el miedo o la orden. Consejo: El

@marcoviaweb

ejercicio de Retromat “¿Por qué estás aquí?” es un buen inicio para una retrospectiva de vez en cuando. Día de la marmota La retrospectiva nunca cambia en composición, lugar o duración. En este caso, es probable que el equipo vuelva a revisar los mismos problemas una y otra vez, como el día de la marmota, sin el final feliz. Realizarlo en el siguiente Sprint El equipo pospone la retrospectiva hasta el próximo Sprint. Más allá de la tarea de "inspeccionar y adaptar", una retrospectiva sirve como un momento de cierre, ayudando a reajustar la mente de todos para que el equipo pueda centrarse en el objetivo del próximo Sprint. Esa es la razón por la que tenemos una retrospectiva antes de planificar el Sprint de seguimiento. Posponer una retrospectiva hasta el próximo Sprint también puede interrumpir el flujo del equipo, retrasando así posibles mejoras. Por estas razones, es importante realizar una retrospectiva antes de planificar el siguiente Sprint. #NoDocumentation Nadie está tomando minutos para su uso posterior. Una retrospectiva es una inversión sustancial por muchas razones y debe tomarse en serio. Tomar notas y fotos apoya el proceso. Sin seguridad psicológica Cada retrospectiva es un ciclo interminable de culpas y señalamientos. En el equipo ganan o pierden todos. Desafortunadamente, el juego de la culpa indica tanto el fracaso del Scrum Master como el facilitador de una retrospectiva como la falta de madurez y habilidades de comunicación de un equipo. Intimidación Uno o dos miembros del equipo dominan la retrospectiva. Este comportamiento de comunicación es a menudo el signo de un Scrum Master débil o desinteresado. La retrospectiva debe ser un lugar seguro donde todos, los introvertidos incluidos, puedan abordar los problemas y proporcionar sus comentarios de forma gratuita de los miembros del equipo que dominan la conversación, intimidan o intimidan a otros compañeros de equipo. Si no se proporciona un lugar seguro, los participantes abandonarán la retrospectiva y los resultados quedarán obsoletos. Es responsabilidad principal del Scrum Master garantizar que todos puedan ser escuchados y que tengan la oportunidad de expresar sus pensamientos. Según Google, el tiempo de habla distribuido de manera equitativa fomenta y significa un equipo de alto rendimiento.

@marcoviaweb

Alerta de Stakeholders Los Stakeholders participan en la retrospectiva. Hay muchas ceremonias de Scrum que abordan las necesidades de comunicación de las Stakeholders: la revisión del Sprint, el refinamiento del Product Backlog, los Standups, sin mencionar las oportunidades para conversar en los enfriadores de agua, tomar un café o durante el almuerzo. Si esas posibilidades de comunicación aún no son suficientes, celebre reuniones adicionales. La retrospectiva es para el equipo y debe estar fuera del alcance de los stakeholders. Pasividad Los miembros del equipo están presentes, pero no están participando. Existen muchas razones para tal comportamiento: los miembros del equipo consideran que la retrospectiva es una pérdida de tiempo, no es seguro o los participantes están aburridos por su capacidad de predicción. Los miembros del equipo también pueden temer las repercusiones negativas si estuvieran ausentes ... o quizás se contrató involuntariamente un grupo homogéneo de introvertidos. Cualquiera sea la razón, es probable que no haya una solución rápida. El Scrum Master debe determinar qué estilo de retrospectiva funcionará mejor en el contexto de su organización. Pregunta 47 ¿Cómo puede usted (como Scrum Master) identificar dónde se necesita mejorar? ¿Cómo puede un Scrum Master identificar dónde se necesita mejorar? Es una pregunta simple, con una respuesta simple: un Scrum Master debería preguntarle a su equipo y a los Stakeholders cómo creen que se podría mejorar. Scrum Masters pueden ejecutar retrospectivas en sí mismos. Una retrospectiva dedicada es mucho más efectiva que pedir sugerencias sobre cómo se puede mejorar durante los últimos minutos de las retrospectivas regulares del equipo.

@marcoviaweb