Una vez que la Guía de Scrum presenta las ideas básicas y los valores detrás del marco, la parte práctica se abre con el equipo de Scrum. De manera similar, cuando hablamos de la estructura básica de Scrum y los primeros días, Jeff Sutherland nos cuenta cómo comenzó todo con el equipo de desarrollo. La razón de esto es muy simple: el equipo de desarrollo es el núcleo de toda la experiencia de Scrum y todos los eventos y artefactos están ahí para ayudar y apoyar al equipo en la entrega de valor.

La organización básica del equipo de Scrum (tamaño, roles, responsabilidades) es bien conocida y (generalmente) seguida de cerca para proporcionar una piedra angular sólida para la práctica de Scrum. Sin embargo, como la mayoría de los practicantes de Scrum pueden testificar, el Scrum Team tiene más que ver con el éxito.

Un equipo de Scrum necesita encontrar el equilibrio en la forma en que sus miembros cumplen sus roles y administran sus interacciones, un equilibrio que permitirá que las ideas subyacentes de Scrum tengan tanto impacto beneficioso en el trabajo del equipo como sea posible.

Scrum Master

El Scrum Master es uno de los dos roles individuales en un equipo de Scrum y no sorprende que sea crucial para el equipo que el Scrum Master deba cumplir bien su rol. Esto requiere una gran cantidad de equilibrio para poder brindar el apoyo que el equipo (y la organización) necesita, pero sin exagerar ni obstaculizarlo.

Por ejemplo, una de las principales responsabilidades del Scrum Master según la Guía de Scrum es eliminar los impedimentos al equipo de desarrollo. Esto es bastante sencillo, ¿cierto?

En casos del mundo real, sin embargo, esto a veces se entiende en el sentido de que se supone que el Scrum Master se da cuenta y elimina por sí solo cada impedimento que encuentra el equipo de desarrollo. En ese entorno, el equipo de desarrollo puede terminar siendo fácilmente mimado, nunca enfrentado problemas y de hecho negandose a si mismos la oportunidad de crecer como una unidad.

En otras palabras, un Scrum Master querrá equilibrar para ayudar aún más al equipo de desarrollo con los impedimentos que encuentra, pero aún así capacitar al equipo lo suficiente como para permitirles manejar algunos problemas por sí mismos.

Otra responsabilidad común del Scrum Master es garantizar que las partes interesadas externas entiendan qué las interacciones con el equipo son beneficiosas y cuáles disruptivas. Esto es especialmente común en organizaciones grandes con muchas estructuras y prácticas tradicionales aún vigentes.

A veces, la respuesta de un Scrum Master a esto será actuar como un escudo para el equipo, desviando la mayoría de las interacciones en la creencia de que el equipo debe estar protegido contra estas intrusiones a toda costa.

Si bien esto está justificado en ciertos casos, también puede ser contraproducente al promover un cierto tipo de aislamiento del equipo, convirtiéndolo en un silo, una de las cosas que se supone que previene Scrum. Este enfoque aislacionista también puede conducir a un sentimiento de desconfianza dentro de la organización.

Una vez más, un Scrum Master necesita equilibrar la protección del equipo contra el comportamiento verdaderamente intrusivo desde el exterior y evitar la integración al proporcionar oportunidades para que las partes interesadas externas obtengan información sobre el trabajo del equipo.

Product Owner

El rol del Product Owner está muy claramente definido en la Guía de Scrum y las responsabilidades y las interacciones son teóricamente muy sencillas. En la práctica, sin embargo, encontrar el equilibrio que funcionará para lo mejor del equipo puede ser difícil.

Por ejemplo, un Product Owner puede tener dificultades para encontrar la mejor manera de expresar los elementos del Product Backlog, ya sea proporcionando muy poca información o demasiada. En tales situaciones, el Scrum Master y el equipo de desarrollo deben involucrarse y brindar asistencia.

Otra cosa que el Product Owner necesita para equilibrar es el valor de las entradas al ordenar el Product Backlog, ya sea para poner énfasis en los requisitos del negocio o para tener en cuenta la información del equipo de desarrollo que podría requerir una priorización alternativa.

En algunas situaciones del mundo real, más comúnmente en organizaciones donde los procesos de desarrollo de software tradicionales habían precedido al enfoque ágil, un Product Owner puede tener dificultades para alejarse de comportamientos pesados e control que no tienen cabida en Scrum. Pueden surgir problemas similares en situaciones en las que el Product Owner formal no forma parte de la misma organización que el resto del equipo (por ejemplo, en la externalización de desarrollo de software).

En tales situaciones, es esencial tener un enfoque equilibrado de esto para no agriar la relación entre el Product Owner y el resto del equipo. El Scrum Master debe tomar la iniciativa y encontrar la mejor manera de educar al Product Owner en cuestión.

AYUDA A TU EQUIPO A LOGRAR SUS OBJETIVOS

Eventos de Scrum

Cuando hablamos del Scrum Team como una unidad, no podemos separarlo de los eventos de Scrum, cuyo propósito es proporcionar un marco para las interacciones internas y externas.

Anteriormente escribimos sobre las diferentes reuniones que el equipo de Scrum tendrá como parte de su práctica y cubrimos los conceptos básicos. Lo que no llegamos a discutir fue la naturaleza innatamente sensible de estas reuniones y el potencial de llevarlas a cabo. De acuerdo con el tema de nuestro artículo, encontrar el equilibrio adecuado suele ser suficiente para evitar que esto suceda.

Daily Scrum

Hay una serie de formas en que la reunión Daily Scrum puede salirse de control. Por ejemplo, los miembros del equipo pueden perder su enfoque y dar vueltas incesantemente sobre temas que se supone que no serán discutidos en esta reunión. A veces, los equipos van por el camino opuesto, donde todos corren por sus propios medios mientras otros esperan su turno y nadie escucha a nadie más.

Encontrar el equilibrio entre los dos es crucial para un Daily Scrum exitoso. Las personas deberían involucrarse y pedir ayuda si la necesitan, pero no debería convertirse en una reunión de una hora en la que las personas discutan los aspectos técnicos o planifiquen el resto del Sprint.

Revisión de Sprint

Cualquiera que haya pasado más de unos pocos meses en un entorno de Scrum sabrá que una Revisión de Sprint sin participación de los interesados s casi inútil. Quizás no del todo, pero definitivamente cercano.

En el otro lado del espectro, también hay revisiones de Sprint donde el equipo de Scrum está saltando a través de aros y siendo interrogado por las partes interesadas. Es seguro decir que este tampoco es el ambiente más saludable de la Revisión de Sprint.

Lo que, una vez más, nos lleva a la cuestión del equilibrio en el que las partes interesadas estarían involucradas, pero donde no se convertirían en supervisores que constantemente denigran y presionan al equipo de Scrum.

“La buena noticia es que la mayoría de los Stakeholder o son así, de todos modos.”

Sprint Retrospective

Como las reuniones más "personales" de Scrum, las Retrospectivas del Sprint requieren bastante equilibrio para desenterrar las verdaderas observaciones y sentimientos de los miembros del equipo sobre el rendimiento.

Por ejemplo, no es raro encontrar Retrospectivas de Sprint que concluyen que todo es excelente y que no hay absolutamente ningún problema. Esto, en sí mismo, es un problema y hay innumerables razones de por qué está sucediendo esto:

• El equipo simplemente no está lo suficientemente comprometido

• Los miembros del equipo no se sienten cómodos hablando sobre los problemas que se deben a las acciones de otra persona

• El equipo necesita una forma más formal de documentar los impedimentos

• Si bien estos pueden abordarse, es importante no ir por el otro lado y convertir la Retrospectiva de Sprint en un evento de tipo real de batalla donde las personas están en la garganta del otro y donde domina la negatividad.

También es importante llevar algo de estructura a las Retrospectivas de Sprint, pero sin convertirlas en ceremonias artificiales en las que los miembros del equipo realizan los movimientos simplemente para marcarlos en la lista.

Como mencionamos, un buen equilibrio con las Retrospectivas.

Sprint Planning

No hay un buen Sprint sin una buena planificación de Sprint y para hacerlo bien, el equipo necesita caminar una línea muy fina.

Por ejemplo, al analizar el objetivo que debe alcanzar Sprint y los elementos del Product Backlog que recomiendan para lograrlo, el Product Owner debe encontrar ese equilibrio entre darle al equipo de desarrollo algo de espacio para respirar y al mismo tiempo desafiarlos (especialmente si el Scrum Master cree que el equipo puede manejar el desafío).

Las negociaciones sobre la cantidad de trabajo que se incluirá en el Sprint también deben manejarse con cuidado y, sobre todo, empíricamente. Todos deberían respaldar sus opiniones con los datos existentes y encontrar un arreglo que funcione para todos.

Una vez que se acuerde el resumen de Sprint, el equipo de desarrollo querrá tener una idea muy clara de cómo piensan trabajar en los elementos del Product Backlog que fueron aceptados en el Sprint, pero deben tener cuidado de no excederse y probarlo. Planear cada minuto de cada día en el Sprint.

En lugar de una palabra de cierre

En el núcleo mismo de Scrum, encontramos transparencia, inspección y adaptación. Cuando se practican correctamente, estos ayudarán al equipo de Scrum a facilitar la búsqueda del equilibrio que, a su vez, permitirá que el equipo sobresalga.

También se debe señalar que incluso cuando el equipo lo crea y sus prácticas estén en perfecto equilibrio, siempre hay espacio para mejorarlo.

Artículo Original: https://www.vivifyscrum.com/insights/scrum-team-finding-the-balance?utm_source=twitter&utm_medium=post&utm_campaign=scrum+team+finding+balance