¿Qué se espera de los diferentes niveles de carrera de un Scrum Master?

Creo que los diferentes niveles pueden relacionarse con Agile Onion como lo describe Simon Powers .

Nivel de entrada : puede implementar las herramientas y los procesos, pero no tiene una buena comprensión de por qué existen los procesos, las prácticas, los principios y los valores. Podría conducir a Agile de culto a la carga .

Intermedio : puede trabajar a nivel de equipo, pero aún no tiene la experiencia para cambiar organizaciones. Entiende los principios y valores, pero puede que aún no sea el mejor para enseñar a otros Scrum Masters. Pero debería entrenar a los equipos en prácticas ágiles como la excelencia técnica .

Senior : Ayuda a la gerencia a crear cambios estructurales y culturales en la organización para volverse más ágil. Lidera el camino a través de Agile Fluency .

Gurú : Lidera transformaciones Agile exitosas (más grandes), escribe libros, etc.

En nuestra organización, los SM junior facilitan la cadencia del proyecto. Se aseguran de que se lleven a cabo las reuniones, se aseguran de que estén presentes las personas adecuadas, ayudan a los miembros del equipo a organizarse por sí mismos y también hacen un seguimiento de cosas como el avance de los puntos de la historia, etc. tiene que administrar. Al igual que con la definición clásica de scrum ágil, siempre buscan impedimentos y buscan eliminarlos.

Los SM de nivel medio son generalmente obvios debido a sus habilidades con las personas. Los SM de nivel medio son líderes (no en el sentido tradicional de gerente, pero son alguien a quien el equipo tiende a mirar y en quien confiar). Los SM de nivel medio son excelentes para generar cohesión en el equipo y la moral del equipo tiende a ser alta. En este nivel, el Sm tiende a sentirse mucho más cómodo usando su experiencia para mirar los sprints pasados ​​y poder hacer proyecciones sobre el trabajo futuro que los hacen muy útiles para los tipos de PMO. Un SM de nivel medio no solo puede ayudar a facilitar una reunión de planificación, sino que también tiene experiencia con el equipo y puede aportar estimaciones de lo que podría o no ser un elemento demasiado grande para asumir en función del desempeño anterior. Esto tiende a ayudar mucho a los líderes tecnológicos y BA.

Los SM senior tienden a ser absorbidos por las funciones de gestión que son (en mi opinión) el área débil del scrum ágil. Los SM sénior a menudo participan en la organización de iniciativas de todo el proyecto, manteniendo los esfuerzos de SQA encaminados (organizacionalmente), asegurándose de que los equipos cubran las áreas necesarias cuando se trata de problemas de lanzamiento, priorización de defectos, etc. Para un proyecto más grande, tienden a llenar el vacío dejado donde la "autoorganización" básicamente falla (algo más de 40 personas más o menos) y asume muchos roles tradicionalmente cubiertos por un personal de PM o PMO. Desafortunadamente, esto significa que los SM senior a menudo están demasiado divididos entre demasiadas responsabilidades.

Júnior

Un maestro de scrum junior debe comprender y ser capaz de explicar los principios fundamentales y las ideas fundamentales detrás de Agile. Deberían poder explicar a los miembros más reacios de un equipo por qué están haciendo Agile.

Los JSM (si puedo acortarlo de esa manera) deberían poder facilitar y mediar en todas las ceremonias ágiles básicas a un nivel muy informal e informal. Esto incluiría standups diarios, planificación de sprints, refinamiento de backlog, revisión de sprints y reuniones retrospectivas. Deben comprender el propósito básico de cada reunión y proporcionar al equipo cierto nivel de dirección, así como dirigir la reunión sin entrometerse. Permita que las conversaciones correctas sucedan de forma natural, pero también evite que se vayan por la tangente.

Intermedio

En este nivel, el scrum master necesita comprender mejor el trabajo del equipo y explicarlo o proporcionar actualizaciones sobre las cosas si es necesario. Los ISM deberían comenzar a ayudar con la admisión de trabajo. Deben poder tener discusiones básicas con el analista comercial del equipo y otras partes interesadas para ayudar a definir y desglosar los requisitos y documentar el trabajo, y para asegurarse de que los requisitos y la capacidad de entrada de trabajo estén de acuerdo con los objetivos del equipo y las capacidades de sprint anteriores. Deben poder trabajar con el propietario del producto para comprender las prioridades y luego deben asegurarse de que los planes de sprint del equipo coincidan con esas prioridades, y ayudar al equipo a comunicar al PO cualquier retraso, bloqueo o trabajo inesperado que se presente.

El scrum master también debe actuar como promotor de obstáculos. Deberían poder ayudar a escalar y resolver las cosas para que el equipo pueda trabajar de manera más eficiente, y deberían comenzar a observar la dinámica entre equipos. Por ejemplo, durante las retrospectivas, deben comenzar a ver si ciertos miembros del equipo están causando problemas a otros y buscar formas de remediarlo. Deberían sentirse más cómodos teniendo discusiones difíciles cuando sea necesario ("su comportamiento está perjudicando a su equipo, ¿qué ideas tiene para solucionarlo?"). No asume el rol de gerente, pero sí tiene que administrar ciertas cosas día a día y asegurarse de que el equipo cumpla con sus compromisos. El scrum master debe sentirse como una parte integral del equipo y debe celebrar los éxitos de su equipo y sentirse mal por las cosas que ralentizan a su equipo.

Los ISM deben ayudar al equipo a administrar su acumulación en términos del trabajo duro de hacer tarjetas y completar los detalles de los requisitos y priorizar el trabajo de las discusiones con las partes interesadas; deberían poder tomar algunas notas sobre lo que se necesita hacer e ir a hacerlo más tarde, sin perder un tiempo valioso durante las reuniones ágiles que podría usarse para la colaboración y el debate del equipo.

Las reuniones deben volverse más estructuradas y formalizadas. La acumulación del equipo debe estar bien documentada, ya sea digital o físicamente, y se debe hacer un esfuerzo para garantizar que las tarjetas se muevan en cada standup, y los miembros del equipo deben ser responsables de proporcionar una actualización. Si no pueden estar físicamente presentes en la reunión, deben proporcionar una actualización por correo electrónico o algún otro medio, haciendo que otra persona los reemplace. El equipo debe sentir que están sincronizados. Debe haber un documento de acuerdos de trabajo publicado en algún lugar y todo el equipo debe estar al tanto y haberlo votado para ponerlo en práctica.

Los ISM deberían comenzar a ayudar a su equipo a ser más autoorganizados y confiar cada vez menos en el Scrum Master. Cuanto mayor sea su habilidad, menos se les debería exigir, en cierto modo reduciéndose a un segundo plano y siendo menos un participante activo y más un habilitador y un observador.

Sénior

En el nivel superior, los maestros de scrum deben desarrollar un sentido refinado de las debilidades y fortalezas de su equipo y deben desarrollar un plan para abordar específicamente esos hallazgos. Deben sentirse cómodos dirigiéndose al equipo como un todo y con cierta autoridad, solo para motivarlos y permitirles hacer su mejor trabajo. Deben poder abordar las infracciones y alentar al equipo a adoptar más prácticas ágiles. En este nivel, el cambio de "hacer Agile" a "ser Agile" debería estar completo. Deben comprender cuándo su equipo se siente incómodo o se resiste a ser ágil, incluso cuando esas preocupaciones no se expresan en voz alta.

Deben poder adelantarse al juego y ayudar al equipo a reaccionar ante los disruptores, obtener una resolución rápida o al menos ayudar al equipo a comunicar los obstáculos de manera efectiva y determinar qué hacer con las partes interesadas adecuadas. Deben ser expertos en recibir comentarios y mejorar, no solo el equipo sino también ellos mismos y cómo facilitan las ceremonias ágiles. Deben usar bien cada reunión, profundizar en la carga de trabajo del equipo, publicar cada triunfo y, cuando ocurren problemas, llegar al meollo de lo que salió mal y cómo solucionarlo en el futuro.

Deben responsabilizar a su equipo por sus acuerdos de trabajo y no tener miedo de desafiar a los miembros del equipo y ponerse duros cuando sea necesario. Esto aún debe hacerse en un estado de ánimo Agile, estando dispuesto a adaptarse si el equipo decide en su conjunto que las cosas deben cambiar. Tener una idea de dónde está el equipo y lo que están pensando debería ser fácil en este punto. El documento del acuerdo de trabajo debe refinarse aún más y capturar las políticas del equipo para las reuniones ágiles y los aprendizajes de errores pasados. El Scrum Master sénior debe poder mediar y resolver conflictos entre los miembros del equipo y mantener las reuniones del equipo enfocadas y productivas.

En esta etapa, deben asegurarse de que todo el trabajo se divida en tareas del tamaño de un sprint antes del comienzo de un sprint, y que durante el sprint el trabajo se divida aún más en trabajo del tamaño de un día o más pequeño, de modo que las tarjetas se puedan mover durante el standup diario. Los standups deberían ser obligatorios en este punto, aunque el horario sería algo flexible.

La retrospectiva en particular debería ser bastante detallada y realmente debería hacer pensar al equipo. Los maestros senior de scrum saben cómo pulir hasta el último detalle de su equipo sin tener que rogar por ello, y cómo ayudar a que cada persona participe y disfrute haciéndolo.

El SSM debe convertirse en el "hombre detrás de la cortina", ayudando al equipo en su madurez ágil sin interferir y enseñándole al equipo a ejecutar los procesos Scrum por su cuenta cada vez más.

Gurú

Los gurús de Scrum Master deberían poder enseñar lo que saben y asesorar a los nuevos Scrum Masters. Deben conocer Agile por dentro y por fuera y ser capaces de explicar y defender sus principios básicos con facilidad. Deben poder adaptar su enfoque a un equipo individual y deben ser expertos en leer a las personas y comprender las interacciones del equipo.

Deben tener un gran entusiasmo por Agile y ser capaces de relacionar cualquier situación con su principio Agile correspondiente. Deberían poder realizar las ceremonias de scrum de manera admirable para cualquier equipo, ya sea nuevo en Agile o bastante maduro. Deben tener múltiples planes e ideas para cada aspecto de ser Agile, y poder seleccionar rápidamente el mejor que se aplique a cada escenario o a cada equipo o incluso individualmente. Deben poder desarrollar rápidamente un conocimiento técnico profundo de la carga de trabajo de su equipo que les permita ser mucho más productivos y eficientes. Deben ser capaces de explicar el trabajo que realiza el equipo en detalle y tomar decisiones menores relacionadas con la entrada de trabajo, y deben rechazar los intentos de sobrecargar el trabajo atrasado del equipo o mantener al equipo a una velocidad anterior.

Deben poder enseñar al equipo a autoorganizarse y administrar su propio trabajo pendiente, y manejar las reuniones y ceremonias ágiles sin problemas y sin intervención ni moderación. Deben ejemplificar las prácticas ágiles y ser capaces de aceptar las críticas del equipo, incluso solicitarlas, y usarlas para mejorar. Deberían poder ayudar al equipo a mejorar, pero hacerlo siendo básicamente invisibles.

TL;RD

Está intentando aplicar una jerarquía heredada a un marco que rechaza explícitamente la noción de una jerarquía de equipo. Esto convierte a la pregunta en sí misma en un antipatrón dentro de Scrum.

Si bien los departamentos de recursos humanos y los gerentes de línea a menudo necesitan hacer este tipo de distinciones por razones organizacionales o políticas que no tienen nada que ver con el marco Scrum o los valores y principios del manifiesto ágil, especialmente en culturas u organizaciones con mucha distancia de poder , la única forma correcta La respuesta dentro del marco de Scrum es no hacer estas distinciones en absoluto. El Equipo Scrum es colectivamente responsable del éxito o fracaso de sus procesos y entrega, y las definiciones externas de antigüedad no son relevantes para esa responsabilidad.

Análisis y Recomendaciones

La Guía Scrum 2020 no hace tales distinciones. Solo hay tres roles/responsabilidades definidos dentro del marco, y no hay provisión para el tiempo en el grado o los niveles de experiencia para los títulos de los roles.

Dicho esto, ciertamente hay equipos maduros y (en el sentido de CMMI ) equipos inmaduros. También hay personas que son nuevas en el marco o en su rol dentro de él. Sin embargo, si bien esta distinción puede ser útil para determinar cómo ayudar al equipo a adoptar el marco o adaptarse con éxito a él, es importante comprender que el marco Scrum no reconoce tales distinciones:

Dentro de un Equipo Scrum, no hay sub-equipos o jerarquías.

Además, la antigüedad no es intrínsecamente relevante para los procesos internos del Equipo Scrum . Si bien un Equipo Scrum es idealmente multifuncional, lo que significa que el equipo colectivamente tiene todas las habilidades necesarias para entregar valor en cada Sprint, los individuos dentro del equipo a menudo tienen diferentes conjuntos de habilidades y niveles de experiencia. Eso significa que depende del equipo determinar cómo compartir la responsabilidad colectiva de la entrega porque:

[Un equipo Scrum] se autogestiona, lo que significa que decide internamente quién hace qué, cuándo y cómo.

Dado que no existen jerarquías formales y todos los desarrolladores son simplemente "desarrolladores", tales decisiones generalmente se basan en quién es el más adecuado para una tarea determinada. En este caso, "más adecuado" es a menudo una evaluación que el equipo realiza colectivamente en función de las habilidades individuales de todos, la composición del equipo y la capacidad disponible de cada persona para asumir el trabajo dentro del Sprint actual. Esto siempre debe ser cierto, independientemente del rango o título externo de una persona fuera del Equipo Scrum. En última instancia, todo el Equipo Scrum es responsable de la entrega de la Meta del Sprint y el Incremento del Producto para el Sprint, y las distinciones que intenta hacer no cambian eso.

Si su organización elige hacer tales distinciones fuera del Marco Scrum, es probable que sea por razones financieras o culturales. Esto está dentro del ámbito de autoridad de la alta dirección. Sin embargo, consideraría que el rol del propietario del producto, el Scrum Master y (en menor medida) el equipo Scrum en su conjunto es ayudar a educar a la organización sobre por qué esto va en contra de la agilidad y tratar de ayudar al liderazgo sénior a venir. con una mejor manera de evaluar la efectividad de sus Equipos Scrum y de contratar/despedir/recompensar a las personas en función del desempeño individual si eligen hacerlo a pesar de la clara evidencia de la industria de que se trata de un antipatrón de agilidad.

El liderazgo senior siempre es responsable en última instancia del "tono en la parte superior". Si rompen el proceso de Scrum, deliberadamente o no, entonces se quedan con ambas mitades. QED

Nota final: las definiciones son relativas

También vale la pena señalar que las diferencias en la experiencia, y el valor monetario o político de esas diferencias, a menudo son relativas. Si bien muchas organizaciones de TI a menudo desarrollan su propio léxico o tiempo en grado para los niveles de experiencia (por ejemplo, muchas empresas usan 5 años como un punto de corte arbitrario, mientras que otras usan el método de 10,000 horas , frecuentemente desacreditado ), la realidad es que el Las distinciones suelen ser idiosincrásicas y específicas de la empresa y, a menudo, se formulan en función de una combinación de la cultura empresarial existente, el dominio del problema específico y los niveles de experiencia actuales (como sea que se definan) del personal existente.

Como ejemplo, suponga que tengo más de 20 años de experiencia en ciertos lenguajes de programación. Si solo tiene 10, pero es mejor que yo en ese idioma, ¿cuál de nosotros es "mayor"? Si he sido un experto profesional en la materia (SME) en algo durante una década, pero tienes un dominio de la misma materia con cinco años de experiencia, ¿eso te convierte en un "SME oficial" o somos compañeros de quizás algunas experiencias profesionales diferentes?

Considere también este contraejemplo. ¿Qué pasa si he estado trabajando mi trasero durante tres años para ser lo mejor que puedo ser en algo, mientras que tú has estado descansando en una cómoda sinecura durante cinco? ¿Cuál de nosotros es probable que tenga más experiencia o sea más adecuado para un proyecto determinado? ¿Quién de nosotros merece más un aumento o una bonificación?

Yo diría que estas distinciones son a la vez relativistas y en gran medida irrelevantes para el valor que una persona determinada puede aportar a un rol, un equipo o un proyecto. Aquí es donde las evaluaciones basadas en resultados para todo el Equipo Scrum suelen ser más valiosas que tratar de asignar un valor intrínseco a títulos arbitrarios o al tiempo en grado individual. Sus valores organizacionales ciertamente variarán, pero la verdad subyacente de la proposición no lo hará.

Como Scrum Master, encontrará que tiene muchas opciones de carrera. Cuanta más experiencia tenga con Scrum, descubrirá que puede asumir el rol de entrenador ágil, mentor y guía, gerente de producto o propietario del producto, o mucho más. Un Scrum Master puede convertirse en un experto en transformación organizacional ayudando no solo a un equipo sino a varios equipos y departamentos de la organización. Pueden asesorar a los equipos de gestión, las organizaciones de clientes, otros equipos de Scrum, etc. para que eventualmente desempeñen un papel crucial en el desarrollo y la transformación de la organización.